[Bug libstdc++/42733] New: Use of std::string with threads causes process hanging following a fork()

[Bug libstdc++/42733] New: Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

Use of std::string with threads causes process hanging following a fork()


-- 
           Summary: Use of std::string with threads causes process hanging
                    following a fork()
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: appfault at hotmail dot com


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

------- Comment #1 from appfault at hotmail dot com  2010-01-13 17:56 -------
Created an attachment (id=19577)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19577&action=view)
code to reproduce

Strangely double-forking seems to also make this go away.  I can't find any
previous zilla that mentions this, so it may be pure luck that some later
versions work.


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[jwakely dot gcc at gmail dot com]

------- Comment #2 from jwakely dot gcc at gmail dot com  2010-01-13 18:23 -------
Can you attach a debugger or produce a core file to see where it hangs?

In any case, 3.4.6 is unsupported now and it seems to work OK on 4.4.2

Unless you can show where it hangs and/or reproduce it on a current release
it's unlikely anyone will look into this


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

------- Comment #3 from appfault at hotmail dot com  2010-01-13 18:30 -------
#0  __gnu_cxx::__exchange_and_add (__mem=0xb3e005a8, __val=-1) at
atomicity.cc:58
#1  0x0804957f in std::string::reserve (this=0xbfffbe20, __res=3017803168) at
basic_string.h:217
#2  0x08049aa2 in std::string::append (this=0xbfffbe20, __s=0x80a3008 "x",
__n=1) at basic_string.tcc:641
#3  0x08049b1b in std::string::operator+= (this=0xbfffbe20, __s=0x1 <Address
0x1 out of bounds>) at char_traits.h:258
#4  0x0804824d in do_stl_stuff ()
#5  0x0804832c in main ()

It never exits from stack frame 0 - gdb says it's alternating between line 58
and 57, but I don't have the source for those.  atomicity.cc doesn't appear to
be in the gcc tar - where is it coming from?


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2010-01-13 18:49 -------
In your sources you will find it named atomicity.h. But really, please try
again with a maintained compiler, preferably 4.4.x, and in case report back,
thanks.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to work|3.4.4 4.1.2                 |3.4.4 4.1.2 4.4.1 4.5.0
         Resolution|                            |WORKSFORME


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

------- Comment #5 from appfault at hotmail dot com  2010-01-13 18:50 -------
I see that it's auto-generated, but when I did so the file was only 53 lines
long.  The function is assembler anyway, so I'm not sure the line numbers would
mean much.

As far as the asm goes, it loops between offsets 12, 18, 20, in that order.

Dump of assembler code for function _ZN9__gnu_cxx18__exchange_and_addEPVii:
0x0804b378 <_ZN9__gnu_cxx18__exchange_and_addEPVii+0>:  push   %ebp
0x0804b379 <_ZN9__gnu_cxx18__exchange_and_addEPVii+1>:  mov    %esp,%ebp
0x0804b37b <_ZN9__gnu_cxx18__exchange_and_addEPVii+3>:  mov    0x8(%ebp),%ecx
0x0804b37e <_ZN9__gnu_cxx18__exchange_and_addEPVii+6>:  mov    $0x1,%eax
0x0804b383 <_ZN9__gnu_cxx18__exchange_and_addEPVii+11>: nop
0x0804b384 <_ZN9__gnu_cxx18__exchange_and_addEPVii+12>: xchg   %eax,0x80bb00c
0x0804b38a <_ZN9__gnu_cxx18__exchange_and_addEPVii+18>: test   %eax,%eax
0x0804b38c <_ZN9__gnu_cxx18__exchange_and_addEPVii+20>: jne    0x804b384
<_ZN9__gnu_cxx18__exchange_and_addEPVii+12>
0x0804b38e <_ZN9__gnu_cxx18__exchange_and_addEPVii+22>: mov    (%ecx),%eax
0x0804b390 <_ZN9__gnu_cxx18__exchange_and_addEPVii+24>: mov    (%ecx),%edx
0x0804b392 <_ZN9__gnu_cxx18__exchange_and_addEPVii+26>: add    0xc(%ebp),%edx
0x0804b395 <_ZN9__gnu_cxx18__exchange_and_addEPVii+29>: mov    %edx,(%ecx)
0x0804b397 <_ZN9__gnu_cxx18__exchange_and_addEPVii+31>: movl   $0x0,0x80bb00c
0x0804b3a1 <_ZN9__gnu_cxx18__exchange_and_addEPVii+41>: leave
0x0804b3a2 <_ZN9__gnu_cxx18__exchange_and_addEPVii+42>: ret

Not sure what the function is really trying to do.


-- 

appfault at hotmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|3.4.4 4.1.2 4.4.1 4.5.0     |3.4.4 4.1.2 4.4.2


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

------- Comment #6 from appfault at hotmail dot com  2010-01-13 18:52 -------
How could this be marked resolved when no one has even speculated on what the
fix could be?  It may still be broken, but more difficult to repro for some
reason.


-- 

appfault at hotmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|3.4.4 4.1.2 4.4.2           |3.4.4 4.1.2 4.4.2 4.5.0


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2010-01-13 18:56 -------
It's resolved as WORKSFORME not as "in all possible circumstances, with all
possible compilers and libraries that we delivered in the past and we deliver
now and all the possible CPUs and underlying glibcs and OSes we are completely
sure that the library-proper code is absolutely correct". We need a reproducer
for a currently maintained GCC, this is the rule.


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

------- Comment #8 from appfault at hotmail dot com  2010-01-13 20:07 -------
Is there already a test case somewhere else to ensure that pthread_atfork and
such works?


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2010-01-13 20:34 -------
Maybe, but pthread_atfork isn't part of GCC.


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[appfault at hotmail dot com]

------- Comment #10 from appfault at hotmail dot com  2010-01-13 21:09 -------
I didn't mean a test that the pthread_atfork() call works at the pthread layer,
but that GCC's use of pthread_atfork() etc was appropriate, given GCC's use of
pthread_mutex.


-- 


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

[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()

[paolo dot carlini at oracle dot com]

------- Comment #11 from paolo dot carlini at oracle dot com  2010-01-13 21:42 -------
If you have serious reasons to believe that GCC may be using pthreads in the
wrong way in its thin gthreads wrapper, please file a PR about that, with a
testcase. The component of course would not be libstdc++.


-- 


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