+3  A: 

Can you repeat the crash with a basic two line program?

#include <string>

int main()
{
    std::string abc;
    abc = "testString";
}

If that crashes, please post your exact compile / link options?

If not, start paring down your code. Remove things lines a handful at a time until the bug goes away. Once you have some other change you can add to cause the crash and remove to make it go away, that should help you locate the problem.

R Samuel Klatchko
I tested exactly that, with -O2 and -O0 and nothing.
Tom
@Tom - okay, so take my next recommendation. Start paring down the rest of the code until the assignment no longer crashes.
R Samuel Klatchko
+1  A: 

There seem to be nothing wrong with your code. It seems that the memory is somehow corrupted. Could you please post a complete example which reproduces the problem?

Vlad
+6  A: 

This is an initial guess using all information I can extract from your back trace.

You are most likely mixing and matching gcc version, linker and libstdc++ that results an unusual behaviour on the host machine:

  1. libc is the system's: /lib64/libc.so.6
  2. libstdc++ is in a "ThirdParty" directory - this is suspicions, as it tells me it might be compiled elsewhere with a different target - /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
  3. Yet another libstdc++ in /opt: /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491

In addition, GCC may mix the system's ld instead of itself which may cause further weird memory maps usage.

LiraNuna
+1. Having 2 libstdc++s (however that happened) seems very likely to be the cause (or related to the cause) of the problem. I've had problems with passing std::strings across DSOs when using GNU's std::string implementation (it does some optimizations for the empty string that can cause issues) without the extra complications of multiple libstdc++s.
Logan Capaldo
I'm also wondering on the motive to not use distro's native GCC.
LiraNuna
Thanks! This seems like a pretty good reason. I am in the midst of changing my build so that I only use one gcc and it will be the one from the native distro ubuntu's gcc 4.2.4-5. Also, could you go more into detail about the optimizations for an empty string or point me to a site that provides info on this? I'm interested in knowing what it does for an empty string that may cause this type of issue. Thanks again!
bbazso
I changed my code to use the same gcc across the board and this still did not get rig of the crash. The optimization theory seems interesting, but I have yet to find any know issue for this kind of crash in gcc 4.2.4? I do know that if I add -fno-default-inline when compiling, this gets rid of the crash, but I have no idea why?
bbazso
@bbazso: Are you sure your version of GCC uses it's own self-compiled libstdc++?
LiraNuna
The specific problem I was having involved a custom instantiation of `std::basic_string` (long story), but it amounted to roughly [this](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196) problem. I'm not saying this is exactly what you are experiencing, but it seems to be similar.
Logan Capaldo
A: 

Hi,

As you said it's a weird behavior.

To be honnest with i think you are wasting time looking into a possible bug with std::strings. Strings are perfectly safe as long as you are using them well.

Anyway, with the informations you are giving : First, are you using threads ? It's might be a thread problem. Second, you check your program using valgrind. Have you no warnings at all ?

Note : The most critical valgrind's warnings are invalid read and invalid write.

PS : As said in commentary, you should probably use g++ to compile C++ code ;)

Niklaos
A: 

I'm running into a similar issue, with free() being passed an invalid pointer during a std::string operation. In my case, the pointer being passed maps to the following symbol: std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4. So my issue is somehow related to the empty string optimization; maybe yours is also? I used 'info symbol ' to map the symbol BTW.

c.stout