Hi,

     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).

I think it is difficult for us to know whether standard object call
setlocale or not.  Put into another way, I have no idea
whether std::string and std::cout call the setlocale or not in above
code section.

Anyone know the root cause of this core dump?  Thanks a lot.


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

> The environment:  Solaris X86 64bit, Solaris Studio C++ 12 (Sun Studio
> C++) with -mt -pthread and libCstd.so, and use libumem library.

Some older (?) versions of the libCstd.so has poor STL support. I
remember it also used some arcane defines. You can try:
- look for the defines that may solve your porblem
- switch to STLPort

RG, K


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

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! ]

Hi

On Tue,  1 Feb 2011 09:51:02 CST, AnkyHe <ankyhe@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:

Can you use Solaris Studio 12 Update 2?

Note that unless you specify -m64, the output will default to 32bit (I
say that because you mention Solaris X86 64bit). Not that there should
be any problems running 32bit applications.

> // 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

Can you compile with debug information (-g), and get a stack trace with
dbx (or dbxtool/solstudio if you prefer a GUI)?

As already mentioned, can you link with STLport? You'll have to
recompile and link all your code with -library=stlport4. You'll benefit
from much better C++ conformance and better speed.

> Anyone know the root cause of this core dump?  Thanks a lot.

Without either the source code or a stack trace, noone can help much.
Can you check your executable with a tool like Purify, or dbx's run time
checking feature - check -access from the dbx prompt, or with dbxtool,
choose the Run Time Memory Checking tab of the Configure Current Debugged
Session dialog, and check Access Checking.

This source

#include <string>
#include <iostream>
using std::string;
using std::cout;
using std::endl;

int main()
{
    string cn("I am cn");
    string sv("I am sv");
    int ci = 10;

    cout<<"    Counter["<<ci<<"] Name="<<cn<<" Value="<<sv<<endl;
}

works with all of these compiler invocations:

      CC -o a a.cpp
      CC -m64 -o a a.cpp
      CC -library=stlport4 -o a a.cpp
      CC -library=stlport4 -m64 -o a a.cpp

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr


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