Core dump in _smalloc via std::valarray and __rwstd::_RW_array

Question

Hello All,
I am developing shared libraries for Solaris 5.8 using CC v5.4 (Sun Forte 7).
These libraries are integrated with application software built with CC v5.6 (Sun Studio 9) also on Solaris 5.8.
The libraries I supply are accessed via a defined C API by the application using "dlopen".
My libraries in turn depend on other, such as libxerces, libCstd and others.
I have verified that the software libraries work correctly when run in a test harness, whether this is compiled using CC v5.4 or CC v5.6.
The application experiences the following fault:
t@4 (l@4) terminated by signal SEGV (no mapping at the fault address)
0xfeec1c98: _smalloc+0x008c:     ld          [%o1 + 8], %o0
The business end of the stack trace is as follows:
[5] std::valarray<double>::valarray(
[4] __rwstd::_RW_array<double>::_initial_size(
[3] operator new(0x0, ...
[2] malloc(0x1, ...
[1] _smalloc(0x8, ...
I am looking for developers with similar experiences or knowledge of this problem to try and narrow down the possible causes.
I am currently investigating the following possibilities:
Compiler patch or use -xarch=v8plus.
Inconsistent use of "-DRW_MULTI_THREAD -mt" compiler/linker options.
Incompatibility between libCstd & libstlport.
I have already referred to the following forum entries.
http://forum.java.sun.com/thread.jspa?forumID=850&threadID=5069618
http://forum.java.sun.com/thread.jspa?threadID=5071063
The code causing this core dump is in the initialisation section of the constructor of a C++ object.
class c {
public:
c(); // constructor
protected:
std:valarray m;
a::a()
// Initialisation.
: m(0) {     <<<<<<<<<< The core dump occurs in the constructor of this valarray member variable.
// Constructor code.
best regards
Geoff Krechting
Edited by: Geoff.Krechting on Apr 23, 2008 5:14 AM
Edited by: Geoff.Krechting on Apr 23, 2008 7:25 AM

Answer 1

Both C++ 5.4 and 5.6 are End Of Life, and little support is available for them. I recommend you upgrade to Sun Studio 11, the most recent compiler that still supports Solaris 8 (which is also End Of Life). Studio 11 is free for all uses, and rebuilding your code using it should not present any problems. You can get it here:
[http://developers.sun.com/sunstudio/products/previous/11/index.jsp]
If you don't want to change compilers, you can still mix binary code from C++ 5.4 and 5.6. The rule is that you can link binaries created by an older compiler into a program or shared library built with a newer compiler, but not the other way around. That is, you need to use C++ 5.6 for all linking steps, not C++ 5.4.
The problem you are running into might be due to a compiler bug, a bug in the runtime library, or a bug in your code.
You can reduce the chances of compiler or library bugs by getting all the current patches for your compilers and libraries here:
[http://developers.sun.com/sunstudio/downloads/patches/index.jsp]
Be sure to update the C++ runtime libraries not only on the computer where you build, but on computers where the application is run.
The crash you are seeing looks like it's due to memory corruption. Memory corruption can be caused by
- using an uninitialized pointer
- using an invalid pointer:
--- points to a deleted object
--- points to an object whose lifetime has ended
- deleting an object more than once
- mis-matched new/delete operations
Using Run-Time Checking in dbx can help you find some of these problems.
% dbx myprog
% check -all
% run