C++ defining two multimaps causes program to crash

Question

This is utterly mystifying me. I have, in my class declaration, two lines:

std::multimap<int, int> commands;
std::multimap<std::string, std::string> config;

The code compiles without issue, but when I run it, I get the following error:

*** glibc detected *** ./antares: free(): invalid pointer: 0xb5ac1b64 ***

Seems simple enough, except that it has nothing to do with how the two variables are later handled. I removed all references in the rest of the code to the variables - still crashed. I commented out one of the lines - either one, and the program ran without issue. How can the error not be with either particular variable? I'm working under the assumption that there isn't a bug in STL, but I've run out of ideas on how my code could possibly be doing this.

This one has me stumped, so I'd appreciate any help you can provide. Wyatt

EDIT: I'm not suggesting there's a problem with STL, that was just me being a bit glib. I know the bug is in my code, what I want to know is - what could possibly be wrong that declaring an unreferenced variable would cause it to crash? Why would that affect my code at all?

My code is a few thousand lines long, so it's not really worth anyone's time reading through it, I'm just looking for someone to point me in the right direction.

Answer 1

You are right: the crash is not from these two lines - they just make it visible.

Here's how to diagnose this problem:

• first, leave your variables defined (make your program crash)

• second, remove or disable other parts of your code until the crash stops happening. Then you will know an approximate area that corrupts your memory.

• third (once you have an area that when disabled stops the crash) start enabling parts of it until the crash happens again.

Edit: I'd say your problem is with code that contains your two multimaps (a copy constructor or assignment operator is missing or something like that). It's just a wild guess so don't put much stock on it.

Answer 2

You're correct to assume the problem isn't in GCC or the STL. However, if the maps are causing free errors, your other code is likely stack smashing (or heap smashing). A truly terrible bug to chase down. The worse part about stack smashing is the object that breaks is not the object with the bug.

Here are some debugging tips.

• Run the app under valgrind.
• define _GLIBCXX_DEBUG to enable stl debugging
• add MALLOC_CHECK_=1 as an environment variable. This will give you better malloc error messages. More info here.
• On rare occasions I have been able to add a memory watch to the location that will be smashed. But it is rare when you can predict where the smashing will occur.