DevOps, CI/CD and Automation

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