为什么'这个'指针在遍历代码时改变其值？ [英] Why 'this' pointer changes its value while stepping through the code?

问题描述

我正在调试崩溃，我注意到通过调试器的一个步骤，这个指针改变它的值，经过3个步骤后，它终于得到值0x00000001，应用程序崩溃。

现在，0x00000001的值显然是错误的，但我真的希望这个值会随着我逐步调试器而改变？

下面是我正在调试的构造函数崩溃的地方。我已经在每个步骤的评论中都包含了这个指针的值，你可以看到它跳过了很多。

  CADOCommand :: CADOCommand（CADODatabase * pAdoDatabase，CString strCommandText，int nCommandType）
 {
 m_pCommand = NULL; 
 m_pCommand.CreateInstance（__ uuidof（Command））; // this = 0x515f9d10 
 m_strCommandText = strCommandText; // this = 0x2c0c0ee8 
 m_pCommand-> CommandText = m_strCommandText.AllocSysString（）; // this = 0x515f9d20 
 m_nCommandType = nCommandType; //这个= 0x70847a55 
 m_pCommand-> CommandType =（CommandTypeEnum）m_nCommandType; // this = 0x00000001 
 m_pCommand-> ActiveConnection = pAdoDatabase-> GetActiveConnection（）; 
 m_nRecordsAffected = 0; 
} 
  

有没有什么价值这个可以或应该更改，因为我们通过给定的成员函数中的代码？

更新

我必须添加记录，并响应几个意见，我正在调试发布版本，但是当我调试相同的功能在调试版本，$ 这个根本没有改变。

那么这是什么意思，发布版本是否有问题？

@drescherjm的评论被upvoted，在发布模式中说这个指针是不正确的，因为优化 不正确是什么意思？我们不能相信这个指针在发行版build（是伪造的）或指针的值是正确的，但由于优化，release build被破坏？

解决方案

根据调试器的不同，看到 c> 该功能和输入。

^{点击 S :: f（）}

后，该地址有效

^{输入 S :: f（）}

但是，一旦你输入了这个功能，值这个不应该ch ange ¹ 。如果是这样，这可能意味着你有一些缓冲区溢出并覆盖堆栈。

解决问题可能很棘手。您可以尝试将内存断点放在这个上，以便在问题消失之前更改或注释掉代码。这应该可以帮你缩小。请注意，罪魁祸首甚至可能不具有这样的特殊功能：内存腐败对于在不相关的地方造成严重破坏是臭名昭着的。

您似乎也在使用优化建立。当使用优化时，非常警惕依靠调试器：变量可能会从代码中消失，给人的印象是它们的值是错误的。如果您可以重现问题，我会尝试在某个地方记录这个，而不是通过调试器查看。这个整个事情可能实际上是一个红色的鲱鱼。

^{1 但是，这个 可以更改，特别是在涉及到虚拟基础时。}

I am debugging a crash and I noticed as a step through the debugger, this pointer changes its value and after 3 steps it finally get the value 0x00000001 and application crashes.

Now the 0x00000001 value is obviously wrong but should I really expect this value to change as I step through the debugger?

Below is the constructor I am debugging where it crashes. I have included the value of this pointer in comments with each step and as you can see it jumps around quite a bit.

CADOCommand::CADOCommand(CADODatabase* pAdoDatabase, CString strCommandText, int nCommandType)
{
    m_pCommand = NULL;
    m_pCommand.CreateInstance(__uuidof(Command)); // this = 0x515f9d10
    m_strCommandText = strCommandText; // this = 0x2c0c0ee8
    m_pCommand->CommandText = m_strCommandText.AllocSysString(); // this = 0x515f9d20
    m_nCommandType = nCommandType; // this = 0x70847a55
    m_pCommand->CommandType = (CommandTypeEnum)m_nCommandType; // this = 0x00000001
    m_pCommand->ActiveConnection = pAdoDatabase->GetActiveConnection(); 
    m_nRecordsAffected = 0;
}

Is there any circumstances where value of this could or should change as we step through the code in a given member function?

Update

I must add for record and in response to several comments, I was debugging release build but when I debugged the same function in debug build, the value of this didn't change after all.

So what does that mean, is there a problem only in release build?

The comment by @drescherjm is upvoted which says in release mode the this pointer is not correct because of optimization but what does that exactly mean by 'not correct'? That we can't trust this pointer in release build (is bogus) or that pointer value is correct but release build is broken because of optimizations?

解决方案

Depending on the debugger, it may be normal to see the value of this change between hitting the function and entering it.

^{hitting S::f()}

^{entering S::f()}

However, once you've entered the function, the value of this shouldn't change¹. If it does, it probably means that you have some sort of buffer overrun and are overwriting your stack.

Figuring out the problem can be tricky. You can try putting memory breakpoints on this to see when it changes or commenting out code until the problem disappears. This should help you narrow it down. Note that the culprit might not even be in that particular function: memory corruption is notorious for causing havoc in unrelated places.

You also seem to be looking at this using an optimized build. Be very wary of relying on a debugger when optimizations were used: variables can disappear from your code, giving you the impression that their value is wrong. If you can reproduce the problem, I'd try logging this somewhere instead of looking at it through a debugger. This whole thing might actually be a red herring.

^{1However, this can change when you're calling another member function across a hierarchy, especially when virtual bases are involved.}

这篇关于为什么'这个'指针在遍历代码时改变其值？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！