为什么'这个'指针改变它的价值，而通过代码？ [英] 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; // this = 0x70847a55 
 m_pCommand-> CommandType =（CommandTypeEnum）m_nCommandType; // this = 0x00000001 
 m_pCommand-> ActiveConnection = pAdoDatabase-> GetActiveConnection（）; 
 m_nRecordsAffected = 0; 
} 
  

是否有 code>可以或应该改变，因为我们在给定的成员函数中的代码。

更新
$ b

我必须添加为记录，并响应几个评论，我是调试发布版本，但是当我调试相同的功能，在debug build， this 没有改变。

这是什么意思，只有在发布版本中有问题吗？

@drescherjm的注释被upvoted，它在发布模式中表示这个指针因为优化而不正确，这是什么意思是不正确？我们不能信任发布版本中的这个指针（是假的），或者指针值是正确的，但是由于优化，发布版本被破坏了。

的值 c> 在 之间切换 =nofollow>

^{击中 S :: f（）}

后，此地址有效

^{输入 S :: f（）}

但是，一旦输入函数， 此不应更改 ¹ 。如果是这样，这可能意味着你有一些缓冲区溢出并覆盖你的堆栈。

找出问题可能很棘手。您可以尝试在 上放置内存断点，以查看更改或注释代码的时间，直到问题消失。这应该帮助你缩小。请注意，罪魁祸首可能不在那个特定的功能：内存损坏是臭名昭着的，在无关的地方造成破坏。

你也似乎在使用优化建立。在使用优化时，要非常谨慎地依靠调试器：变量可以从代码中消失，给你的印象是它们的值错了。如果你可以重现这个问题，我试试记录这个在某处，而不是通过调试器看。

^{1 但是， this}

当您在层次结构中调用另一个成员函数时，

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屋！