core dump from dying multithreaded process

My multithread application (C++, SunOS) is dynamically linked with shared libraries. There are several threads in the program, some of them are from the libraries. One of such threads calls exit() and it results in generating core dump from another thread in shared library:

(dbx) where
  [1] 0x0(0xbeee0b30, 0x0, 0x0, 0x1c00, 0x1, 0xbeee0b50),开发者_JS百科 at 0x0
  [2] STLCollectionWrapper<std::vector<SM_Timer*,std::allocator<SM_Timer*> > >::empty(0xbeee0b30, 0x0, 0x0, 0x1c00, 0xbca12200, 0x0), at 0xbee04690
  [3] GenPtrSortVec<SM_Timer,std::less<SM_Timer>,std::allocator<SM_Timer> >::isEmpty(0xbeee0b30, 0x0, 0x0, 0x0, 0x4fb0e0, 0xbd436b90), at 0xbee04424
  [4] sm_tmr_process(0x341000, 0x8e400, 0xbeeba00f, 0x1c00, 0x1, 0xbeee0800), at 0xbee03968
  [5] sm_nm_process_timeouts(0xbc67bf94, 0xbc67bf98, 0xbd4c3800, 0x0, 0xbca12200, 0xbee830f0), at 0xbee813dc
  [6] TimerThreadObject::poll(0x0, 0xbc67c000, 0x0, 0x0, 0xbedf1530, 0x1), at 0xbedf15f4
(dbx) thread
current thread ($thread) is t@null
(dbx) lwps
  l@1 LWP suspended in __SLIP.FINAL__A()
  l@3 LWP suspended in find_composition_start()
o>l@6 signal SIGSEGV in 0x0()

The stack frames 6-4 are from libA, frames 3-2 from libB. Frame 1 must have been called from C++ standard library (/usr/lib/libCstd.so.1?). As you see, this call failed.

At frame 4 the code called isEmpty() method of global object of type GenPtrSortVec. This object is located in the stack in the same module where the method sm_tmr_process() is defined. Later at frame 2 the code called empty() method of STL vector object. This vector is a field of GenPtrSortVec class.

I have the following questions regarding this issue:

1. Why the first frame has address 0x0?

2. Is it possible that libCstd had been unloaded from the dying process prior to cancelling all threads in the program? Note that libCstd was automatically loaded into the process as a dynamic dependency.

And two more questions about exiting from the process:

1. Is it possible that automatically loaded shared libraries had been automatically unloaded prior to cancelling all threads and destroying the global/static objects?

2. Is it possible that global or static objects had been destroyed prior to cancelling all threads?

1.1 - possibly a null pointer call (see Jörgen)

1.2 - no

2.1 - no

2.2 - possibly

1.2/2.1: Shared libraries are loaded when the program is loaded in memory. The dynamic linker will then scan through all external references and fix them up. This is the process of dynamic linking. This won't be undone, i.e. no library loaded this way will be unloaded by the OS. The whole process image is trashed once the program terminates.

2.2 - that depends on your application. Initialization of global/shared objects can be problematic - see the static initialization fiasco. The same applies for destruction. The order in both cases is implementation defined.

Answer to 1: You probably called a NULL function pointer. Possibly not directly, but indirectly. Could you have overwritten the vtable of an object with zeros, and then called on of its virtual methods?