Uncaught exception in solaris using sun 5.4 c++ compiler
I have built a shared object library that throws an exception. When this shared object is called by one of the companies we work with, the exception is never caught and core is dumped. On our system the exception is caught. On linux and windows, the exception is caught. I am building the shared object using sunCC 5.4, latest patch on solaris 5.8. The system the exception is not caught is a solaris 5.9 machine with sunCC 5.5. Lists of patches installed on this machine is below.
I have built a shared object that throws an exception :
BEGIN CODE**********************
if ( idx < 0 || idx >= mNobs )
throw adco_ETsInvalidIndex( this, idx, year, period );
This exception's class and the classes it derives from are as follows (along with a comment that explains how the base adco_cError class works):
class adco_ETsInvalidIndex: public adco_cErrorStore
{
private:
// static const char* msgtext;
// static const char* alttext;
public:
adco_ETsInvalidIndex( const adco_TimeSeries* ts, int i, int y, int p );
adco_ETsInvalidIndex( const adco_TimeSeries* ts, int idx );
};
class adco_cErrorStore: public adco_cErrorImp {
public:
adco_cErrorStore( const adco_cEnumElem sev, const char* msg = NULL );
adco_cErrorStore( const adco_cErrorStore& e);
~adco_cErrorStore();
};
class adco_cErrorImp: public adco_cError {
public:
adco_cErrorImp( const adco_cEnumElem sev, char* msg = NULL );
adco_cErrorImp( const adco_cErrorImp& e )
: mSeverity(e.mSeverity), mMessage( e.mMessage ), mMsgLen( e.mMsgLen ), mGError(e.mGError) {}
adco_cEnumElem severity() const { return mSeverity; }
const char* message() const { return mMessage; }
unsigned int msglen() const { return mMsgLen; }
adco_cEnumElem msgelement() const { return mGError; }
protected:
adco_cEnumElem mSeverity;
char* mMessage;
unsigned int mMsgLen;
adco_cEnumElem mGError;
};
BASE CLASS******************************
//
// Base class for all thrown adco model errors
// When a specific error is thrown, it's copy constructor
// is used to copy the the error from the error context to the heap.
// After the stack is cut back, destroying the original error instance,
// the base copy constructor is used to copy a BASE CLASS adco_cError
// instance into the error handler (catch block) context.
// This base class instance will contain an mRealMe that points
// to the heap copy of the real error.
// When the handler context is exited, the heap copy of the real error
// and the base class instance in the handler context are destroyed.
// For this reason, the base copy constructor is smart. An attempt to
// copy a base class error instance out of the handler will yield a
// mRealMe that points to itself, and the original error info is lost.
//
class ADPPMDL_API adco_cError
{
protected:
const adco_cError* mRealMe;
adco_cError() { mRealMe = this; }
public:
adco_cError( const adco_cError& e);
virtual adco_cEnumElem severity() const;
virtual const char* message() const;
virtual unsigned int msglen() const;
virtual adco_cEnumElem msgelement() const; // in Global System ERRORDEFS list, or NULL_ELEM
}; /* class ADPPMDL_API adco_cError */
END CODE***************************************************
This throw gets through multiple catch() statements (the main one being catch(adco_cError & err). There is also a catch( ... )). Some statements are in the same library that throws the exception. Some are in wrapper libraries. It gets through all of them.
This works in Windows and Linux. It also works when called on our own computer. WHen we send the libraries (both the c wrapper and library that throws the exception) to one of the other companies that we we work with, however, the exception is not caught.
Details on our setup:
CC: Forte Developer 7 C++ 5.4 Patch 111715-17 2005/10/13
uname -X
System = SunOS
Node = aablade1
Release = 5.8
KernelID = Generic_108528-13
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 1
I have installed all the latest patches for Forte Developer 7 on Solaris 8 from http://developers.sun.com/sunstudio/downloads/patches/index.jsp
I am not linking with -B symbolic. The wrapped libraries (which are a C wrapper around the library that throws the exception and in turn load the library that throws the exception) are loaded with RTLD_GLOBAL by the company's system that does not catch the exception.
Details on the system on which the exception is not caught:
General Information
Host Name is medusa
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
Manufacturer is Sun (Sun Microsystems)
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
System Model is Fire 880
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
ROM Version isOBP 4.7.5 2003/01/08 11:36
Number of CPUs is8
CPU Type is sparc
App Architecture issparc
Kernel Architecture issun4u
OS Name isSunOS
OS Version is5.9
Kernel Version isSunOS Release 5.9 Version Generic_117171-05 [UNIX(R) System V Release 4.0]
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
Kernel Information
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
SysConf Information
Max combined size of argv[] and envp[] is1048320
Max processes allowed to any UID is 29995
Clock ticks per second is100
Max simultaneous groups per user is 16
Max open files per process is256
System memory page size is8192
Job control supported isTRUE
Savid ids (seteuid()) supported is TRUE
Version of POSIX.1 standard supported is199506
Version of the X/Open standard supported is 3
Max log name is8
Max password length is 8
Number of processors (CPUs) configured is8
Number of processors (CPUs) online is8
Total number of pages of physical memory is 4456448
Number of pages of physical memory not currently in use is 2791486
Max number of I/O operations in single list I/O call is 4096
Max amount a process can decrease its async I/O priority level is0
Max number of timer expiration overruns is 2147483647
Max number of open message queue descriptors per process is 32
Max number of message priorities supported is32
Max number of realtime signals is8
Max number of semaphores per process is2147483647
Max value a semaphore may have is2147483647
Max number of queued signals per process is 32
Max number of timers per process is 32
Supports asyncronous I/O isTRUE
Supports File Synchronization isTRUE
Supports memory mapped files is TRUE
Supports process memory locking is TRUE
Supports range memory locking isTRUE
Supports memory protection isTRUE
Supports message passing isTRUE
Supports process scheduling is TRUE
Supports realtime signals isTRUE
Supports semaphores is TRUE
Supports shared memory objects isTRUE
Supports syncronized I/O isTRUE
Supports timers is TRUE
sysinfo: /dev/ksyms is not a 32-bit kernel namelist
Device Information
SUNW,Sun-Fire-880
cpu0 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu1 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu2 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu3 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu4 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu5 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu6 is a "900 MHz SUNW,UltraSPARC-III+" CPU
cpu7 is a "900 MHz SUNW,UltraSPARC-III+" CPU
Patches installed on this machine:
111721-04
111722-04
115113-01
113823-03
114806-02
114807-02
114808-02
114809-02
115108-02
115109-02
115110-02
115111-02
115112-02
115980-02
113820-03
112760-18
117828-01
112763-19
113817-15
114801-08
112762-16
108434-21
108435-21
111711-15
111712-15
Any ideas what might cause this? We have spent a lot of time trying to figure out the cause.
Thanks.
Will
will@ad-co.com
