tags:

views:

252

answers:

5

I have a C++ program (GCC) and when I add one or more int members to an abstract base class, the program starts crashing. In the case I've exampled, it seems that by adding this member, a member in a derived class quits getting initialized (or gets stomped on at some point). If I add more members, it starts (not) working different. This is all really odd because the member is never used anywhere. I can comment out that one line and the program recompile just fine and runs without error.

The whole program is ~3KLOC and would be very hard to strip down.

I'm totally at a loss as to where to start looking. Any Ideas?


Update

I found the issue: free-ing malloc-ed memory and delete-ing new-ed memory is not safe in the same program.

+4  A: 

A little more information about the crash would be helpful, as there are mulitple ways a program can crash. However, the first thing I do on Linux if I suspect it could be a memory error is to run the program through Valgrind (Memcheck) and see what it can tell me.

Also as a shot in the dark, is your build system generating dependencies correctly? One possibility is that your modifying the abstract class but not recompiling all the source files which depend on the abstract class, which could be problematic.

Falaina
I'm using the make remakes a makefile thing so I think the dependencies are correct. Also, if I do a full rebuild it doesn't go away. :(
BCS
Since we now know it's not a stale build issue I would go with the valgrind approach suggested here because the next logical thing to test is whether your program only _appears_ to work when the extra members are not present. Running valgrind is straightforward but can be hideously slow so make sure you know how to take the shortest route to the crash :)
Troubadour
the crash happens in about 0.1s so speed shouldn't be a problem.
BCS
+6  A: 

Off the top of my head, without seeing any code (see comments on your question) I would suggest a rogue pointer which normally stomps on something you don't notice, but introducing a new member makes it stomp on something you do notice.

Try adding members of different sizes, or more (unused) int members, or maybe a string in the form: const char xxx[50]; to reserve more space.

quamrana
Now this is interesting: adding a few more int changes the mode of failure. This warrants looking into...
BCS
...with valgrind if your class instance is allocated on the heap. It might be slow but it'll be far quicker than a human squinting at bit patterns in their debugger trying to figure out what's doing the stomping. It'll just give you the complete stack when it happens.
Troubadour
+6  A: 

99 times out of 100 I find that if you change the data structure of a class and you start getting weird crashes then the build dependencies are not quite right i.e. you need to rebuild something that for some reason is not getting rebuilt.

If it's not a major pain to completely clean and rebuild your entire project then I would give that a go and then we can rule this answer out.

Troubadour
That was my first thought once I found where the crash was. No dice.
BCS
Oh well, worth a try.
Troubadour
+1  A: 

Try running your program in gdb.

gdb your_executable

Then hit 'r' then enter when your code crashes you can hit 'bt' then enter to see the offending line of code.

Neel
under one case it gives me a bad stack with `strlen` and `printf` on the top, under another, it gives me some place in `list.h` in `yyparse` in main (I think this is another corrupt stack as main doesn't call `yyparse`)
BCS
can you copy the back trace and put it in a comment? But my initial thought is that somewhere along the way your not safely up casting or down casting a derived object.
Neel
A: 

After you changed the class did you re-compile all the source?

If you only re-compiled the base or derived class (not sure where you put the new int) then all the other objects have the wrong size for your class. You need to delete all the object files and re-build them.

Martin York