Multiple Inheritance gcc bug?


#1

I have some strange corruption happening with multiple inheritance - it seems that two class members from different bases are overlapping in memory (not in identifier name, to be clear)… so when I change one, the same memory location is changed in the other! I’ve looked at this behavior directly with a memory debugger and this is certainly what is happening. Also there is no diamond inheritance going on.

If it matters, the two members in question are a bool and a float pointer.

This memory bug doesn’t occur with VC++ / ICC compiled code, just GCC.

Google hasn’t been kind to me about this, does anyone know why this is happening?


#2

Perhaps you’re slicing an object?


#3

If I understand what that is correctly, I don’t believe so. I’m not assigning any whole objects in the buggy code, merely primitive members. I also speculate that an object slicing bug would persist in VC++ and ICC code.


#4

Well, I changed the bool to an int and there is corruption no more… The bool variables were packed to the bit, so I can only assume there’s a gcc packing problem.


#5

It sounds really unlikely that there’d be a bug like that… Be careful that by changing it to an int you’re not just disguising some kind of mistake that’s still there in your code.


#6

I am inclined to agree based on my statistical blameworthiness :expressionless:


#7

It’s the cause of some other bugs too, but this time moving from bool to int didn’t fix it. :x


#8

are they bitfield values? You can’t get the address of a bitfield member - addresses refer to bytes! if they’re packed then of course they’d have the same address


#9

No those two are both 32bit variables - an int and a float. That is to say only a single true/false value is contained in that int; it’s not a bitfield.


#10

I suggest looking at the disassembly for code accessing this data. This will allow you to see if the compiler is doing something wrong…


#11

I’d also try putting in some debug print-outs to show the addresses of those two variables, because you can’t always trust a debugger to be telling the truth…