0

I've got a strange problem. I've got a program where I'm using some static variables (some of which are objects including other variables) and some of them seem to overlap in memory in _DEBUG_ mode. The program is rather complex and I've not yet had time to reproduce it in a smaller use case. So it looks like this:

struct Bar  
{ 
   int i;
... 
};

class A 
{ 
public:
 Bar b;
... 
};

class B
{ 
public:
 static FOO f;
... 
 static A a;
};

I then set a break point at _tmainCRTStartup in order to see what happens _BEFORE_ any of my code was ran. Once the break point is hit, I'm looking at the variables and their addresses in the Watch window and see the following picture:

&B::f - 0x00fa68e0

&(B::a.b) - 0x00fa68cc 

sizeof(B::a.b) - 28

But (0x00fa68e0 - 0x00fa68cc) = 20

So, these variables overlap in memory (if I change "i", another object will be affected). I started looking at the map file an B::a is defined at 0x00fa6340.

So is this a linker or compiler bug? No code has ran yet, yet there is a memory overlap already here.

Have you come across this in VS 2008?

Is this some known bug, is there a workaround or am I missing something in my code?

Sukrit Kalra
  • 33,167
  • 7
  • 69
  • 71
user1552175
  • 178
  • 10
  • 2
    Most likely, the debugger is lying to you. Perhaps the PDB file is stale somehow. I suggest you actually print the relevant addresses, with cout or printf. This way, you would know what the compiler believes, as opposed to what the debugger believes. – Igor Tandetnik Jul 17 '13 at 20:11
  • @Igor, I thought so in the first place, so did clean/rebuild but the problem remained. I started looking into this in the first place because the program started crashing. During the investigation I saw that when one of the variables is changed , it affects another one deamaticalkt changing its state. I'll try printing for sure when I'm back to workplace but I wanted to check addresses before any code including static inits has ran so I'm sure there's no chance of me corrupting the memory – user1552175 Jul 17 '13 at 20:27
  • 1
    Another possibility is that you have One Definition Rule (ODR) violation. Different translation units see different definitions for one or more of the classes involved, perhaps due to some macro trickery. – Igor Tandetnik Jul 17 '13 at 20:46
  • @Igor, I had a look at the printf. There's enough space for both variables i.e. they don't seem to intersect and I don't think we have ODR (there's just a few places in the code where the class under suspicion is used&I can't see where we could have a second definition). I'd still like to know why PDB is showing this nonsense (no struct packing/padding is on) and we're still getting this crash that is shown as variables overlapping when looking in debug mode. – user1552175 Jul 18 '13 at 00:53
  • I.e. we adjust one variable which results in the counter of the first being set to the wrong value, hence we go outside the borders of the memory allocated for the object. It's really weird behaviour I'm seeing here. – user1552175 Jul 18 '13 at 00:57
  • @Igor, man, thanks for the right direction ODR it was. It was very challenging to track it down in our big project. I came across this article in the end which shares a great compiler switch to find these kind of issues: http://blogs.msdn.com/b/vcblog/archive/2007/05/17/diagnosing-hidden-odr-violations-in-visual-c-and-fixing-lnk2022.aspx. In our specific case it came from BOOST::circular_buffer. In one of the translation units someone defined #define BOOST_CB_DISABLE_DEBUG but it wasn't defined in other translation units so boost::circular_buffer had different size affecting the structure size – user1552175 Jul 18 '13 at 15:07

0 Answers0