Core dump using iostream with Sun Studio 8

Question

I'm running on Solaris 9 using C++ compiler Sun Studio 8, and encoutered a very strange problem.
My application failed with a core and here is the stack.
[1] t_splay(0x3774b470, 0x387a0ec0, 0x389aec60, 0x39e5ef1f, 0x3774b470, 0x1), at 0xfc347930
[2] t_delete(0x387a0ec0, 0x80, 0x39be9748, 0x20, 0x383ccd20, 0x0), at 0xfc347698
[3] mallocunlocked(0x80, 0x0, 0x21b08, 0xfc3bc000, 0x10, 0x20), at 0xfc346d40
[4] malloc(0x80, 0xfbaa7400, 0x1, 0x759c40, 0x0, 0x0), at 0xfc346b74
[5] operator new(0x80, 0x0, 0xd3a18, 0x759c74, 0x0, 0x8345fc), at 0x760c10
[6] strstreambuf::overflow(0xf41f6e28, 0x29, 0xf41f6e28, 0x39fe0e88, 0x39fe0e88, 0x8345fc), at 0x75bb1c
[7] streambuf::xsputn(0xf41f6e28, 0xfee00bc0, 0x1, 0x0, 0x81010100, 0x1), at 0x75ab94
[8] unsafe_ostream::outstr(0xf41f6e78, 0xfee00bbf, 0x0, 0x0, 0xf41f6e7c, 0xfffffffe), at 0x757bac
=>[9] unsafe_ostream::operator<<(this = 0xf41f6e78, _s = 0xfee00bbf ")"), line 1211 in "iostream.h"
[10] ostream::operator<<(this = 0xf41f6e74, _s = 0xfee00bbf ")"), line 1350 in "iostream.h"
[11] CorInterfaceEntity::ifState(this = 0x1bc3de78, newState = MISMATCH_OF_INSTALLED_AND_EXPECTED, needToSendEvent = false
Can somebody help me giving a direction of investigation ?
Is there perhaps known problem with iostream on Sun Studio 8 running on Solaris 9 ?
Thanks for any tips.
Yaakov Berkovitch
[email protected]

Answer 1

But sorry for my insistence, but do you think that
purify or/and runtime are not able to detect any
corruption of the heap ?They can detect some kinds of corruption, such as some uses of an invalid pointer.
But a wild pointer that changes the value of data that is part of your program cannot be detected by RTC or Purify. Those programs can't know whether that change is intentional.
>
BTW, we are not using any volatile declaration, and weIf non-local data is shared among threads, it should be declared volatile. For example, suppose you have
x = foo;
... // code not changing foo
y = foo;
If foo is not marked volatile, the compiler is allowed to assume its value hasn't changed, and assign to y the same value assigned to x. If foo was changed by another thread, y will not have the current value of foo. The "volatile" declaration says that the variable's value might change without any obvious reason, and the compiler should generate code to load a fresh value each time it is referenced.
are using the rwtools library packaged with the
compiler, and are not using the STD library.OK, you are not running into a std::string synchronization bug.
>
Also about the compiler option -xarch=v8, is probably
not relevant for us because we are running Solaris 9.
So the relevant compiler is probably -xarch=v9. Do you
advise us using this option ?I think you misunderstand. The -xarch values refer to the kind of processor your program will run on.
The -xarch=v8 option generates 32-bit code that will run on all SPARC chips, including the chips found in very old SPARCstations. This option is the default for compilers prior to Sun Studio 9 (which ships this week).
The -xarch=v8plus option generates 32-bit code that runs only on UltraSPARC chips, found in Ultra workstations. These are the only kinds of workstations shipped by Sun since about 1996. Unless you need to support the ancient SPARCstations, we recommend compiling with -xarch=v8plus, to get smaller and faster code.
The -xarch=v9 option generates 64-bit code that runs only on UltraSPARC chips, an only on Solaris 7 or later. Unless your program requires a very large address space, you generally don't want to generate 64-bit code. On SPARC, 64-bit code is larger and slower than 32-bit code. (Type "long" and all pointers are 64 bits instead of 32 bits.)
>
Also I want to return you two new questions:
1) I read in another discussion,
http://forum.sun.com/thread.jsp?forum=5&thread=18124&me
sage=47854#47854
that another memory manager can be more efficient in
multi-threaded environment (libmtmalloc.so), and also
an alternate threads library (/usr/lib/lwp) that
reduced CPU usage. Do you advice us using this
alternate library ?The libmtmalloc library usually has better performance in MT programs than the default version of malloc. It also can result in more memory fragmentation. In that case, the larger working set can sometimes have a large negative effect, more than offsetting the MT efficiency. You have to experiment to see whether it is appropriate for your particlular program. If you are running into heap corruption, the pattern of corruption will probably be different with libmtmalloc than with the default malloc. The differences might provide a clue to what is wrong.
The alternative "T2" threads library was introduced in Solaris 8 as an option.
In Solaris 9 it is the default, so you are already using it.
>
2) We are using the Rogue Wave library shiped with the
compiler. Is it an up-to-date version ? Can we assume
that is a good choice or it will be preferable to move
to the STD library ?I assume you mean Rogue Wave Tools.h++. As explained in the compiler docs, this version of Tools is obsolete, and has not been supported for many years. We continue to provide it for customers who used it before the introduction of the C++ Standard Library in 1998, and who don't want to change their code. We do not recommend it for use in new code.