Re: Solaris Studio C++ std::cout std::string core dump under multithread environment.

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++.moderated

Date:

Fri, 4 Feb 2011 19:57:44 CST

Message-ID:

<7ac44bdc-55fe-4447-915b-20009dda66d8@o39g2000prb.googlegroups.com>

On Feb 1, 3:51 pm, AnkyHe <ank...@gmail.com> wrote:

Recently I meet a very strange core dump issue and I investigate
this issue for long time and I have some ideas, however I have no idea
it is correct or not. So I want some guys could give me some
suggestions or tips, thanks a lot.

The environment: Solaris X86 64bit, Solaris Studio C++ 12 (Sun Studio
C++) with -mt -pthread and libCstd.so, and use libumem library.
The core dump point is as follows:

// ci is a int, cn and sv is a string
// and I am sure ci, cn and sv is only function local variables and
they
// aren't shared by multithreads
cout<<" Counter["<<ci<<"] Name="<<cn<<" Value="<<sv<<endl; // core
dump

I refer to <Oracle Solaris Studio 12.2: C++User's Guide> 10.3
"Sharing C++ Standard Library Objects Between
Threads", I snapped some descriptions from the document:
The C++ Standard Library (libCstd -library=Cstd) is MT-Safe, with the
exception of some
locales, and it ensures that the internals of the library work
properly in a multi-threaded
environment. You still need to lock around any library objects that
you yourself share between
threads. See the man pages for setlocale(3C) and attributes(5).

And isn't cout a "library object"? According to this, you have
to lock around cout if you're using it in more than one thread.
(In practice, you'd probably want to anyway, since the best the
library could do still wouldn't prevent your << std::setw
affecting a different thread, rather than the next output in
your thread.)

--
James Kanze

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]