Thread: Any tips on pitfalls involving STL's string?

I have this problem with this CGI I'm writing that involves another library (cgicc) which deals with STL's string class. The problem is a seg fault, and by reading valgrind reports it's clearly a problem of stray pointers and the like. I've spent that last several hours thinking outside the box, which clearly hasn't worked, so now I'm trying to think outside the warehouse and I don't seem to be getting anywhere. Here's the first valgrind report on something wrong:

==9230== Invalid read of size 8
==9230== at 0x4553A8: std::string::string(std::string const&) (basic_string.h:288)
==9230== by 0x45EDD0: cgicc::Cgicc::getElement(std::string const&) (Cgicc.cpp:48)
==9230== by 0x41B82B: Main<cgicc::Cgicc>::Execute() (main_impl.h:22)
==9230== by 0x409447: main (pdf2db.cpp:56)
==9230== Address 0x4073DFF is 23 bytes inside a block of size 29 alloc'd
==9230== at 0x4C22515: operator new(unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==9230== by 0x455080: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:91)
==9230== by 0x45521A: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (basic_string.tcc:151)
==9230== by 0x4552C1: std::string::string(char const*, std::allocator<char> const&) (basic_string.h:1454)
==9230== by 0x41B81B: Main<cgicc::Cgicc>::Execute() (main_impl.h:22)
==9230== by 0x409447: main (pdf2db.cpp:56)

Main is my template class. Everything after that is other people's libraries. Here's the code on line 22 of main_impl.h, fwiw

Code:

		form_iterator _mode = cgi.getElement("mode");

This harkens back to a similar problem I was having involving a debug macro. By defining _GLIBCXX_DEBUG one can get STL to throw exceptions in the event of misuse of an STL feature. I spent rather a long time figuring out that if you try using an STL object returned by a library that wasn't built with that macro turned on, you can get bizarre problems involving seg faults and stray pointers. I've been very thorough in removing all instances of _GLIBCXX_DEBUG from all the code I'm using, which hasn't help this problem--but they smell very similar.

This is why I think it must be some pitfall involving STL, something that doesn't cause compiler errors, but will cause bizarre, unpredictable behavior, just like the inconsistent definition of _GLIBCXX_DEBUG.

I recall that this morning there was an update to glib2, which probably broke cgicc. By rebuilding cgicc the problem went away. I guess it had nothing to do w/STL. That's how far outside the warehouse I had to think!