I understand that __SLIP segments are created by the C++ to do things like constructing static objects, destroying them, and my favorite, thunking them (translating abstract to real class pointers).
So, when I get a crash in a slip segment, how can I trace this back to a source module, or even a source line?
In this case, all I see is a call to __SLIP.FINAL__A. I have not even been able to trace this back to a specific module even, since we have hundreds of __SLIP.FINAL__A segments in different modules.
[code] [2] _resetsig(0x7f35b814, 0x0, 0x0, 0x7c281d98, 0x7f36c000, 0x0), at 0x7f34e56c
[3] _sigon(0x7c281d98, 0x7f3738a8, 0x6, 0x7c2808bc, 0x7c281d98, 0x7f37321c), at 0x7f34dd0c
[4] _thrp_kill(0x0, 0x4, 0x6, 0x7f36c000, 0x4, 0x7f240458), at 0x7f350d4c
[5] raise(0x6, 0x0, 0x0, 0xffffffff, 0x7f2403c4, 0x7f3731fc), at 0x7f1cbcec
[6] abort(0x7f23c008, 0x7c280a10, 0x0, 0xfffffff8, 0x4, 0x7c280a31), at 0x7f1b5984
[7] os::abort(0x1, 0x7c7d7fc6, 0x7c280ac0, 0x7c7f0000, 0x7c805d20, 0x353e44), at 0x7c73d544
[8] os::handle_unexpected_exception(0x0, 0xb, 0x7e081664, 0x7c2817f8, 0xb, 0x0), at 0x7c73b63c
[9] JVM_handle_solaris_signal(0x7e081664, 0x7c2817f8, 0x7c281540, 0x1, 0x0, 0x0), at 0x7c741644
[10] __sighndlr(0xb, 0x7c2817f8, 0x7c281540, 0x7c73efbc, 0x7c281e40, 0x7c281e30), at 0x7f35b138
- called from signal handler with signal 11 (SIGSEGV)
[11] JNIEnv_::DeleteGlobalRef(this = 0x1551ec, gref = 0x36aee8), line 816 in "jni.h"
[12] jace::helper::deleteGlobalRef(env = 0x1551ec, obj = 0x36aee8), line 148 in "JNIHelper.cpp"
[13] jace::JClassImpl::~JClassImpl(this = 0x7d1c5ab8), line 44 in "JClassImpl.cpp"
=>[14] __SLIP.FINAL__A(0x0, 0x0, 0x0, 0x7f19bc98, 0x2844dc, 0x0), at 0x7d1635a0
[15] _exithandle(0x7f2420d4, 0x7f23e608, 0x781c0, 0x2887cc, 0x7c56c7a0, 0x7f23c008), at 0x7f19bca4
[16] exit(0x0, 0x283a00, 0x1, 0x0, 0x7c7f0000, 0x0), at 0x7f21fbb0
[17] VM_Operation::evaluate(0x77a81530, 0x283b78, 0x7c7f0000, 0x159598, 0x39c404, 0x7c5694e0), at 0x7c56c688 [/code]
As you noted, the __SLIP* symbols represent compiler magic to implement operations that do not show up explicitly in source code. In particular, __SLIP.FINAL is a compiler-generated function that calls destructors for static objects. If a module has a static object with a non-trivial destructor, the .o file will have a __SLIP.FINAL function.
(A "non-trivial destructor" is one that is user-defined, or one that is compiler-generated for a class with a member or base that has a non-trivial destructor.)
In dbx, you can trace the implicitly-called destructors by putting a breakpoint on the destructor. Using conditional breakpoints, you can probably avoid stopping on uninteresting destructor calls.
The Sun Studio 12 compilers do this better than Sun Studio 11.
You want to try downloading the latest Sun Studio express release, and you
should be able to see source line information for the __SLIP functions in
the stack trace.
http://developers.sun.com/prodtech/cc/downloads/express.jsp
--chris
