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

  1. #1
    Kung Fu Kitty Angus's Avatar
    Join Date
    Oct 2008
    Montreal, Canada

    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/
    ==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
    		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.

  2. #2
    Kung Fu Kitty Angus's Avatar
    Join Date
    Oct 2008
    Montreal, Canada
    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!

  3. #3
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Ideally, your build system would include all libraries that "exchange" STL objects - with full dependency checks and common build options. That would of avoided both bites. (unless you put _GLIBCXX_DEBUG directly in the source - instead of in a makefile/build system)


Popular pages Recent additions subscribe to a feed

Similar Threads

  1. compare structures
    By lazyme in forum C++ Programming
    Replies: 15
    Last Post: 05-28-2009, 02:40 AM
  2. OOP Question DB Access Wrapper Classes
    By digioz in forum C# Programming
    Replies: 2
    Last Post: 09-07-2008, 04:30 PM
  3. String Manipulation problems -_-
    By Astra in forum C Programming
    Replies: 5
    Last Post: 12-13-2006, 05:48 PM
  4. Message class ** Need help befor 12am tonight**
    By TransformedBG in forum C++ Programming
    Replies: 1
    Last Post: 11-29-2006, 11:03 PM
  5. can anyone see anything wrong with this code
    By occ0708 in forum C++ Programming
    Replies: 6
    Last Post: 12-07-2004, 12:47 PM