[Bug libstdc++/36270] New: A problem with STL map/vector/list whose key is a STL string in multi-threaded application

[Bug libstdc++/36270] New: A problem with STL map/vector/list whose key is a STL string in multi-threaded application

[sveta dot cher at gmail dot com]

Hi,

While developing a multi-threaded application I've encountered a problem that
is reproduced in a testcase presented below. 
The purpose of the sample is to create a large number of threads where each
thread uses stl strings. The threads execute consecutively and not in parallel.
The problem is that the program crashes with a segmentation fault at line 14
(string instantiation in the f function) in thread number 4095 which is the
4097-th created thread (including the main thread). The segmentation fault
doesn't happen if line 23 is removed (assignment of a value into
std::map<string, string> in mt_test function). The problem is also reproduced
if the insertion into map is replaced with insertion into a
std::vector<std::string> or std::list<std::string>. I've found that
mt_allocator.h defines 4096 as the maximum number of threads in the freelist
(_S_max_threads enum) which seems to be related to the problem.

The source code:

#include <iostream>
#include <string>
#include <pthread.h>
#include <stdio.h>
#include <map>
#include <vector>
#include <list>

using namespace std;

void* f(void *arg)
{
        int i = (int)arg;
        string str = "foobar";  // <-- segmentation fault
        cout << "finished:"<< i << endl;
        return 0;
}

void mt_test()
{
        string str1("f");
        map<string, string> myMap;
        myMap[str1] = "akjshd";  // <-- if removed, no crash

        const int NUM_THREADS = 6000;
        void* ret=0;
        for(int i=0;i<NUM_THREADS;++i)
        {
                pthread_t thread;
                int retVal = pthread_create(&thread, NULL, f, (void*)i);
                if (retVal != 0)
                {
                        cout << "error: " << retVal << endl;
                        exit(-1);
                }
                pthread_join(thread, &ret);
        }
}

int main(int argc, char *argv[])
{
  mt_test();
  return EXIT_SUCCESS;
}

System info:

Compiler: GNU C++ version 4.0.0 20050519 (Red Hat 4.0.0-8) (i386-redhat-linux)
Creating the executable with: 
$g++ -v -Wall -lpthread testthread.cpp -o testthread
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=i386-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
 /usr/libexec/gcc/i386-redhat-linux/4.0.0/cc1plus -quiet -v -D_GNU_SOURCE
../src/testthread.cpp -quiet -dumpbase testthread.cpp -auxbase testthread -Wall
-version -o /tmp/ccCvBzFs.s
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0

/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/i386-redhat-linux
 /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/backward
 /usr/local/include
 /usr/lib/gcc/i386-redhat-linux/4.0.0/include
 /usr/include
End of search list.
GNU C++ version 4.0.0 20050519 (Red Hat 4.0.0-8) (i386-redhat-linux)
        compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129317
 as -V -Qy -o /tmp/ccSuAMBj.o /tmp/ccCvBzFs.s
GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD version
2.15.94.0.2.2 20041220
 /usr/libexec/gcc/i386-redhat-linux/4.0.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o testthread
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.0.0/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.0.0 -L/usr/lib/gcc/i386-redhat-linux/4.0.0
-L/usr/lib/gcc/i386-redhat-linux/4.0.0/../../.. -lpthread /tmp/ccSuAMBj.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i386-redhat-linux/4.0.0/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crtn.o

Libraries:
$ ldd testthread
        linux-gate.so.1 =>  (0x0029e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0063b000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00795000)
        libm.so.6 => /lib/libm.so.6 (0x00524000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00753000)
        libc.so.6 => /lib/libc.so.6 (0x003f8000)
        /lib/ld-linux.so.2 (0x003d6000)

Performing a backtrace with gdb gives:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208943696 (LWP 32755)]
0x007d7977 in __gnu_cxx::__pool<true>::_M_get_thread_id () from
/usr/lib/libstdc++.so.6
(gdb) backtrace
#0  0x007d7977 in __gnu_cxx::__pool<true>::_M_get_thread_id () from
/usr/lib/libstdc++.so.6
#1  0x007d7e0c in __gnu_cxx::__pool<true>::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
#2  0x0082227d in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#3  0x0082625f in std::operator+<char, std::char_traits<char>,
std::allocator<char> > () from /usr/lib/libstdc++.so.6
#4  0x00826e7c in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#5  0x08049067 in f (arg=0xfff) at
/home/sveta-c/testthread/src/testthread.cpp:14
#6  0x00640b80 in start_thread () from /lib/libpthread.so.0
#7  0x004c2dee in clone () from /lib/libc.so.6

I would really appriciate any help on the subject.
Thanks in advance,
Sveta.


-- 
           Summary: A problem with STL map/vector/list whose key is a STL
                    string in multi-threaded application
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sveta dot cher at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36270

[Bug libstdc++/36270] A problem with STL map/vector/list whose key is a string in multi-threaded application

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2008-05-20 09:17 -------
Some general comments: The 4.0.x series is not supported anymore, any future
fix will only go in 4.3.x and maybe 4.2.x; I see that you are using mt_alloc,
which, in the FSF official release of GCC is *not* the default allocator, it's
still largely experimental these times and was much more so in 4.0.x times; in
mt_alloc there is unfortunately a compile-time limit on the maximum number of
threads (grep _S_max_threads in mt_allocator.h) and for your applications,
before any other investigation, I think you should experiment with raising that
number (see the ext/mt_allocator/tune-*.cc testcases about changing those
defaults)


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
            Summary|A problem with STL          |A problem with STL
                   |map/vector/list whose key is|map/vector/list whose key is
                   |a STL string in multi-      |a string in multi-threaded
                   |threaded application        |application


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36270

[Bug libstdc++/36270] A problem with STL map/vector/list whose key is a string in multi-threaded application

[sveta dot cher at gmail dot com]

------- Comment #2 from sveta dot cher at gmail dot com  2008-05-27 07:39 -------
(In reply to comment #1)
> Some general comments: The 4.0.x series is not supported anymore, any future
> fix will only go in 4.3.x and maybe 4.2.x; I see that you are using mt_alloc,
> which, in the FSF official release of GCC is *not* the default allocator, it's
> still largely experimental these times and was much more so in 4.0.x times; in
> mt_alloc there is unfortunately a compile-time limit on the maximum number of
> threads (grep _S_max_threads in mt_allocator.h) and for your applications,
> before any other investigation, I think you should experiment with raising that
> number (see the ext/mt_allocator/tune-*.cc testcases about changing those
> defaults)
> 


Thanks for your quick reply.
I have upgraded gcc's version to 4.0.2 and the problem is no longer reproduced.
Nonetheless, there is something in your comment that was not quite clear to me.
You've mentioned that I'm using mt_alloc instead of a default allocator. I'm
not sure where did I make the choice to use it: there is nothing in the code
that specifies which allocator to use (I assumed that in this case the default
will be used). Is it the result of the way the compiler was configured?
Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36270

[Bug libstdc++/36270] A problem with STL map/vector/list whose key is a string in multi-threaded application

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2008-05-27 09:02 -------
(In reply to comment #2)
> Thanks for your quick reply.
> I have upgraded gcc's version to 4.0.2 and the problem is no longer reproduced.

Good. Therefore, I think we can safely close this issue.

> Nonetheless, there is something in your comment that was not quite clear to me.
> You've mentioned that I'm using mt_alloc instead of a default allocator. I'm
> not sure where did I make the choice to use it: there is nothing in the code
> that specifies which allocator to use (I assumed that in this case the default
> will be used). Is it the result of the way the compiler was configured?

Right. For some reason, your distro changed the default for that release.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36270