Segfault with <sstream>

[chronologicaldot]

Is it just my luck that only my application when compiled with <sstream> gives a segfault when run? Just curious if anyone else has run into this problem.

[CuteAlien]

Some lesson a senior programmer tought me early on: It's never the standard library, it's always your bug. After I few decades I can say that so far he was right.

My guess in such cases is that the include changes the memory layout and triggers some unrelated bug.

[CuteAlien]

Hm, just got another idea. Are you using MinGW or cygwin? You may have some troubles there if you use wide-chars in streams (maybe depends on version and clib implementation etc, just something I run into in the past).

[chronologicaldot]

I had a file that included <sstream> in a project that used Irrlicht. The program compiled, but even though none of the code using sstream was run (I can guarantee that), the program segfaulted immediately. In fact, no code was run. When I checked gdb, the error came up in CBSPMeshFileLoader.cpp, which was never used in my project (There are no meshes nor scene-related things in my project), making me even more confused. I ran across errors I'd never seen before.
I don't think the standard library is at fault. I'm using g++, so perhaps it just didn't like the order in which I was including <sstream>. *shrug* I can do without it, fortunately.

[CuteAlien]

It might initialize some globals. That's enough to change memory layout. So the bug might be in the initialization of other globals - or maybe the order of initialization which then gets changed. The fact that it crashes without running code (meaning before it runs main I suppose) also hints at that. So for example you have two globals or statics which are initialized in different .cpp files. Then their order of initialization is undefined and just adding another file like this can flip it.