🔒 Locked

std::string and multithreading

Started by CRACK123 Oct 7, 2006 at 8:32 AM 2 replies 2k views

Original Post

Oct 7, 2006 at 8:32 AM

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

Deyja

125

Deyja

Oct 7, 2006 at 5:23 PM

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.

Kazade

110

Kazade

Oct 8, 2006 at 2:20 AM

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.

joanusdmentia

Oct 8, 2006 at 3:19 AM

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)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.