std::string and multithreading

Started by
2 comments, last by joanusdmentia 17 years, 6 months ago
Hi, I am having some issues with std::string and Posix threads and can't figure out what is wrong with this code with respect to threads. I am getting a core dump with threads when I assign a char * to a string. This is the code where its failing. I am using g++ on Solaris 10 and also followed sun options to enable multi threading for thread safe STL i.e DTHREAD=multi and _RWSTD_MULTI_THREAD

   std::string s(str + lenOffset); // line 116
   std::string::size_type size = 0;
   std::string::size_type found = s.rfind("HTTP");
   
   while(size != found)
   {
      while(size != found && s[size] == '/') size++;
      std::string::size_type j = size;
      
      while(j != found && s[j] != '/') j++;
      if(size != j)
      {
         dirStruct.push_back(s.substr(size, j - size));          
         size = j;
      }
   } 


I am not sure what I am missing here - should I not be doing something that I am doing. This is the error when I do a back trace using gdb.

Program terminated with signal 10, Bus error.
#0  0xfeed4dd8 in t_splay () from /usr/lib/libc.so.1
(gdb) where
#0  0xfeed4dd8 in t_splay () from /usr/lib/libc.so.1
#1  0xfeed4c68 in t_delete () from /usr/lib/libc.so.1
#2  0xfeed487c in realfree () from /usr/lib/libc.so.1
#3  0xfeed5104 in cleanfree () from /usr/lib/libc.so.1
#4  0xfeed425c in _malloc_unlocked () from /usr/lib/libc.so.1
#5  0xfeed414c in malloc () from /usr/lib/libc.so.1
#6  0xff146948 in operator new (sz=67)
    at ../../../../gcc-4.1.1/libstdc++-v3/libsupc++/new_op.cc:57
#7  0xff125194 in std::string::_Rep::_S_create (__capacity=67,
    __old_capacity=4273970566, __alloc=@0x0)
    at /scratch/emil/gcc/objdir/sparc-sun-solaris2.10/libstdc++-v3/include/ext/new_allocator.h:88
#8  0xff126284 in std::string::_S_construct<char const*> (
    __beg=0x36 <Address 0x36 out of bounds>, __end=<value optimized out>,
    __a=@0xfee30400)
    at /scratch/emil/gcc/objdir/sparc-sun-solaris2.10/libstdc++-v3/include/bits/basic_string.tcc:150
#9  0xff1263e4 in basic_string (this=0xfebf997f,
    __s=0x36 <Address 0x36 out of bounds>, __a=@0xfebf9d87)
    at /scratch/emil/gcc/objdir/sparc-sun-solaris2.10/libstdc++-v3/include/bits/basic_string.h:1449
#10 0x00015058 in BuildDirectoryList (
    req=0x35070 "GET http://www.test.com/gif/button_advancedsearch.gif HTTP/1.1") at server3_final.cpp:116
#11 0x0001505c in BuildDirectoryList (
    req=0x35070 "GET http://www.test.com/gif/button_advancedsearch.gif HTTP/1.1") at server3_final.cpp:116
Previous frame identical to this frame (corrupt stack?)


Thanks
The more applications I write, more I find out how less I know
Advertisement
If you're using threads, you need to handle concurency. Even with standard library classes. The standard library is 'threading agnostic'. You have to handle all concurency yourself.
There is a section here on multi-threading issues. However ignore the part about deriving a class from std::vector<> thats generally not a good idea. You should be able to get an idea on how the lock works though.
Member of the NeHe team.
Is 'str' shared in another thread? If not, then this probably isn't a multithreading issue. In fact, looking at the stack trace I'd say that 'str' is NULL, you're adding 0x36 to it (to get the "HTTP/1.1"), and then passing that through (ie. address 0x36) to std::string's constructor ('__s' in line #9 of the stack trace)
"Voilà! In view, a humble vaudevillian veteran, cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valorous visitation of a bygone vexation stands vivified, and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition. The only verdict is vengeance; a vendetta held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose, so let me simply add that it's my very good honor to meet you and you may call me V.".....V

This topic is closed to new replies.

Advertisement