[Bug c++/32261] New: Thread race segfault in std::string::append with -O and -s

[Bug c++/32261] New: Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

Compiling with:
g++ -g -O3 gccbug.cpp -pthread -o gccbug -s

Note that removing the -s eliminates the segfault, as does removing
optimizations with -O0.

This occurs with gcc 3.3 and 3.3.6 but does not occur with the gcc 3.2.3
delivered as part of RedHat ES3.0u5.  It is also fixed in 3.4.6.

#include <pthread.h>
#include <string>

void* thread_function(void*) {
    for (int k = 0; k < 50000; k++) {
        std::string my_str;
        my_str += "foo";
    }
    return 0;
}

int main()
{
    pthread_t thread1, thread2;

    pthread_create(&thread1, NULL, thread_function, NULL);
    pthread_create(&thread2, NULL, thread_function, NULL);

    void* exitcode;
    pthread_join(thread1, &exitcode);
    pthread_join(thread2, &exitcode);

    return 0;
}

Example stack trace (as a courtesy to future googlers looking for this issue):
#0  0x00d3d4cc in memcpy () from /lib/libc.so.6
#1  0x00ba9120 in std::string::_Rep::_M_clone (this=0x804a700,
__alloc=@0x2012783, __res=28) at
/build_gnu_build/gcc-3.3.6/i386-redhat-linux/libstdc++-v3/include/bits/char_traits.h:155
#2  0x00ba7519 in std::string::reserve (this=0xb6bf43b0, __res=28) at
/build_gnu_build/gcc-3.3.6/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.h:257
#3  0x00ba77be in std::string::append (this=0xb6bf43b0, __str=@0xb6bf43a0) at
/build_gnu_build/gcc-3.3.6/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:680
#4  0x08048c21 in ?? ()
#5  0x080490da in ?? ()
#6  0x08049093 in ?? ()
#7  0x08048fa6 in ?? ()
#8  0x003ef9d9 in start_thread (arg=0xb6bf4bb0) at pthread_create.c:261
#9  0x00d86f0e in clone () from /lib/libc.so.6


-- 
           Summary: Thread race segfault in std::string::append with -O and
                    -s
           Product: gcc
           Version: 3.3.6
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: appfault at hotmail dot com
  GCC host triplet: 2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686
                    i686 i3


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

[Bug c++/32261] Thread race segfault in std::string::append with -O and -s

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-08 19:50 -------
>It is also fixed in 3.4.6.

Well then it is fixed as 3.3.x is no longer being maintained and has not been
for over a year (or two).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.4.6


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

[Bug c++/32261] Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

------- Comment #2 from appfault at hotmail dot com  2007-06-11 16:01 -------
I wouldn't consider the bugzilla itself to be fixed until a regression test has
been added to the gcc test suite.

Can you confirm that this test case has been added to the gcc regression test
suite?  I searched the testsuites for 3.4.6 and don't see anything comprable to
my test case.


-- 


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

[Bug c++/32261] Thread race segfault in std::string::append with -O and -s

[jlawson-gcc at bovine dot net]

------- Comment #3 from jlawson-gcc at bovine dot net  2007-06-12 01:36 -------
This seems like a rather unexpected crash given the seemingly valid example
code.  Can anyone from the GCC team indicate the actual compiler issue that
might cause this example to fail, and specifically indicate an existing
bugzilla number that addressed it?

I'm worried that this issue may very well have been unintentionally hidden and
not actually fixed.  (For example, a casual code change might have altered
segment alignments and symbol offsets happen to overflow differently.)


-- 

jlawson-gcc at bovine dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlawson-gcc at bovine dot
                   |                            |net


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

[Bug c++/32261] Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

------- Comment #4 from appfault at hotmail dot com  2007-06-13 17:38 -------
Yes in addition to the issue of adding a test case, it is quite unsettling to
not know what might have fixed it.  Reopening pending response to comment 2 and
comment 3.


-- 

appfault at hotmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-14 01:27 -------


*** This bug has been marked as a duplicate of 21334 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[jlawson-gcc at bovine dot net]

------- Comment #6 from jlawson-gcc at bovine dot net  2007-06-14 02:42 -------
bug 21334 seems to deal with multiple threads accessing the same shared object
at the same time.  However, the sample code provided here involves separate
private objects so there should not be any such issues.  If it is not possible
to assume that separate threads can access unrelated STL objects at the same
time, then this would imply that all STL operations (regardless of the object)
must be serialized!


-- 


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

Re: [Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[Andrew Pinski]

> bug 21334 seems to deal with multiple threads accessing the same shared object
> at the same time.  However, the sample code provided here involves separate
> private objects so there should not be any such issues.  If it is not possible
> to assume that separate threads can access unrelated STL objects at the same
> time, then this would imply that all STL operations (regardless of the object)
> must be serialized!

The empty string is the same object really.

-- Pinski

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pinskia at gmail dot com]

------- Comment #7 from pinskia at gmail dot com  2007-06-14 02:56 -------
Subject: Re:  Thread race segfault in std::string::append with -O and -s

> bug 21334 seems to deal with multiple threads accessing the same shared object
> at the same time.  However, the sample code provided here involves separate
> private objects so there should not be any such issues.  If it is not possible
> to assume that separate threads can access unrelated STL objects at the same
> time, then this would imply that all STL operations (regardless of the object)
> must be serialized!

The empty string is the same object really.

-- Pinski


-- 


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pcarlini at suse dot de]

------- Comment #8 from pcarlini at suse dot de  2007-06-14 08:15 -------
Note, however, that startiing with 3.4.x (vs 3.3.x) the empty string
representation is not not reference counted anymore. First blush, the
*specific* code snippet in this PR should be safe.


-- 


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

------- Comment #9 from appfault at hotmail dot com  2007-06-25 23:41 -------
So does this being marked dupe of bug 21334 mean that as long as <string> (not
ext/vstring.h) is in use, that std::string is subject to other possible race
conditions, even if the original test case succeeds in gcc 3.4.x?


-- 


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pcarlini at suse dot de]

------- Comment #10 from pcarlini at suse dot de  2007-06-25 23:50 -------
Probably, the answer is yes. In this area, when writing portable code, always
remember that C++03 says *nothing* about threads, and concurrent programming,
and so on. Different implementations, historically, made different choices,
different routes and trade-offs. That means that in general, if you cannot
optimize for the implementation defined details of a specific implementation,
you end-up locking a lot, for safety. That's unfortunate, I agree. The next C++
standard (and ext/vstring.h ;) will be better, certainly.


-- 


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

------- Comment #11 from appfault at hotmail dot com  2007-07-09 23:21 -------
I've been unable to reproduce any issues in 3.4.6, even with tests that do not
rely on the empty string.  I suspect there is something more specific that was
fixed somewhere between 3.3.x and 3.4.6.

It doesn't seem appropriate to have marked this as a dupe of bug 21334, since
bug 21334 has had no code changes made, but clearly a code change was made at
some point to fix the comment 0 report.

I recommend the comment 0 test be added to the gcc regression test suite, after
which this zilla could be reclassified as 'fixed'.


-- 


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

------- Comment #12 from appfault at hotmail dot com  2007-09-24 17:48 -------
Due to lack of responsiveness, a separate Bug 33394 was opened for the missing
test case.  Verified this is generically in concept a duplicate of bug 21334,
although the technical details are in fact not the same.


-- 

appfault at hotmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |VERIFIED


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