[Bug libstdc++/50703] New: std::stringstream not thread-safe

[Bug libstdc++/50703] New: std::stringstream not thread-safe

[Hoenle2007@kayser-threde.com]

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

             Bug #: 50703
           Summary: std::stringstream not thread-safe
    Classification: Unclassified
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Hoenle2007@kayser-threde.com


Our multi-threaded software (running on the SPARC compatible LEON3 processor
for space applications under the RTEMS 4.9.4 operating system) always locks up
at the same location outside the application software in libstdc++. See
attached debugger screenshot. The error arises between several minutes and
several hours of operation.

We were able to reproduce the problem with GCC/libstdc++ 4.2.4 and with 4.3.2.
We haven't tested newer versions.

The error apparently happens when the GNU library function __atomic_add() in
atomicity.cc is called very often, probably when being called from different
threads.
It could also be possibe that the error is not located in atomicity.cc but
already in its caller std::stringstream (in basic_ios.h).

We are pretty sure the application software can't do anything wrong at this
time as just the std::stringstream constructor is being called for an object on
the stack. See attached debugger screenshot.

We fixed the problem by replacing "std::stringstream" with our own class that
uses "printf" internally. Since then the application software never again
locked up.

[Bug libstdc++/50703] std::stringstream not thread-safe

[Hoenle2007@kayser-threde.com]

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

--- Comment #1 from Hoenle2007@kayser-threde.com 2011-10-12 15:36:50 UTC ---
Created attachment 25475
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25475
debugger screenshot

[Bug libstdc++/50703] std::stringstream not thread-safe

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-10-12
     Ever Confirmed|0                           |1

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-12 15:39:32 UTC ---
First, 4.2.x is very old and not maintained anymore. Thus, before anything
else, please try 4.6.x or 4.5.x. Then, before taking any action, we need a
short, self contained reproducer (as specified in the bug reporting
instructions).

[Bug libstdc++/50703] std::stringstream not thread-safe

[Hoenle2007@kayser-threde.com]

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

--- Comment #3 from Hoenle2007@kayser-threde.com 2011-10-13 07:56:47 UTC ---
I will try libstdc++ 4.6.x or 4.5.x. Question: May I use this new library with
the relatively old compiler I am currently utilizing or do I need to upgrade to
a newer compiler version also?

[Bug libstdc++/50703] std::stringstream not thread-safe

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-13 08:11:42 UTC ---
You cannot use libstdc++ separately from the GCC version it ships with, so to
use libstdc++ 4.6.1 you must use G++ 4.6.1

[Bug libstdc++/50703] std::stringstream not thread-safe

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-13 12:01:56 UTC ---
was gcc built with a non-default value for --enable-clocale ?

what locale is being used by the application?

[Bug libstdc++/50703] std::stringstream not thread-safe

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-13 12:22:45 UTC ---
Note that in case problems persist, a testcase is *required* for anything
concrete to happen. It's impossible to diagnose in any serious detail
thread-safety issues without knowing the code, trying it's just a huge waste of
time, we know that. Also note, just in case isn't already obvious, that C++98
doesn't talk about threads *at all*, thus very little is guaranteed in a
non-implementation defined way.

[Bug libstdc++/50703] std::stringstream not thread-safe

[Hoenle2007@kayser-threde.com]

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

--- Comment #7 from Hoenle2007@kayser-threde.com 2011-10-17 08:17:21 UTC ---
@Jonathan: You ask "was gcc built with a non-default value for --enable-clocale
?". I don't think so. We perform cross development on Windows with MinGW as
supported out-of-the-box by the RTEMS operating system distribution. With that
distribution the cross compilation tools come already pre-compiled. Maybe the
following gcc output helps:

$ sparc-rtems-gcc -v
Reading specs from
c:/opt/rtems-4.8-mingw/bin/../lib/gcc/sparc-rtems/4.2.4/specs
Target: sparc-rtems
Configured with: ../gcc-4.2.4/configure --target=sparc-rtems --host
i686-mingw32 --build i486-slackware-linux --with-gnu-as --with-gnu-ld
--with-newlib --verbose --enable-threads --enable-languages=c,c++ --disable-nls
--prefix=/opt/rtems-4.8-mingw --enable-version-specific-runtime-libs
--with-system-zlib --disable-libstdcxx-pch --disable-win32-registry
--without-included-gettext
Thread model: rtems
gcc version 4.2.4

-----------------

@Paolo: We never access a std::stringstream object from different threads but
always from a single thread. When we share objects between threads, we protect
them by a pthread mutex. I will perform a test with a new GCC/libstdc++
probably mid November. In case the problem persists I will try to set up a
short, self contained reproducer.

-----------------

Regards
Alfred

[Bug libstdc++/50703] std::stringstream not thread-safe

[liuxiaopi349 at hotmail dot com]

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

peter <liuxiaopi349 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liuxiaopi349 at hotmail dot com

--- Comment #8 from peter <liuxiaopi349 at hotmail dot com> ---
Hi, Hoenle2007, 
Do you have any update on this?
Encountering a probably similar case on ostringstream (not 100% sure). It is in
Centos Linux in x86_64 platform with older stdlib like 4.1.   Just want to know
what is final conclusion on the thread safty of stringstream/ostringstream as
the case you mentioned in this post.

Regards,


(In reply to Hoenle2007 from comment #7)
> @Jonathan: You ask "was gcc built with a non-default value for
> --enable-clocale ?". I don't think so. We perform cross development on
> Windows with MinGW as supported out-of-the-box by the RTEMS operating system
> distribution. With that distribution the cross compilation tools come
> already pre-compiled. Maybe the following gcc output helps:
> 
> $ sparc-rtems-gcc -v
> Reading specs from
> c:/opt/rtems-4.8-mingw/bin/../lib/gcc/sparc-rtems/4.2.4/specs
> Target: sparc-rtems
> Configured with: ../gcc-4.2.4/configure --target=sparc-rtems --host
> i686-mingw32 --build i486-slackware-linux --with-gnu-as --with-gnu-ld
> --with-newlib --verbose --enable-threads --enable-languages=c,c++
> --disable-nls --prefix=/opt/rtems-4.8-mingw
> --enable-version-specific-runtime-libs --with-system-zlib
> --disable-libstdcxx-pch --disable-win32-registry --without-included-gettext
> Thread model: rtems
> gcc version 4.2.4
> 
> -----------------
> 
> @Paolo: We never access a std::stringstream object from different threads
> but always from a single thread. When we share objects between threads, we
> protect them by a pthread mutex. I will perform a test with a new
> GCC/libstdc++ probably mid November. In case the problem persists I will try
> to set up a short, self contained reproducer.
> 
> -----------------
> 
> Regards
> Alfred