[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:	DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:	Welcome to the Digital UNIX Conference
Moderator:	SMURF::DENHAM

Created:	Thu Mar 16 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	10068
Total number of notes:	35879

9742.0. "Help request on thread stack dumps ..." by TAEC::GALLERI () Wed May 07 1997 10:28

Hi guys,

I have a customer that is currently experimenting application
crashes that lead to the following kind of dbx `tstack' result:

dbx version 3.11.8
Type 'help' for help.
Core file created by program "rfg_shell"
thread 0xfffffc0004568640 signal Trace/BPT trap at >*[__kill,
0x3ff8051b658]    beq     r19, 0x3ff8051b670

(dbx) tstacki
Thread 0xfffffc0004568640:
>  0 __kill(0x5, 0x0, 0x0, 0x0, 0x0) [0x3ff8051b658]
   1 exc_raise(0x3ffc056de78, 0x0, 0x0, 0x0, 0x0) [0x3ff8057003c]
   2 exc_pop_ctx(0x3ffc056dbd0, 0x0, 0x0, 0x3ff8057b620, 0x14010cc90)
[0x3ff80570240]
   3 cma__thread_base(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80581e50]

Thread 0xfffffc00078a63c0:
>  0 (unknown)(0x3ffc01a8800, 0x11ffff434, 0x11ffff490, 0x0, 0x3ff804b937c) 
[0x3ff80589384]
   1 __cma_tis_mutex_unlock(0x11ffff490, 0x0, 0x3ff804b937c, 0x2,
0x3ff804b77f0) [0x3ff804b9228]
   2 __rec_mutex_unlock(0x3ffc01a87f0, 0x11ffff434, 0x8, 0x11fffe0c8,
0x10000002e) [0x3ff804b77ec]
   3 __exc_lookup_function_entry(0x12006a160, 0x11fffe0a8, 0x67, 0x0,
0x0) [0x3ff80518ee8]
   4 exc_lookup_function_entry(0x67, 0x0, 0x0, 0x0, 0x1202cfd98)
[0x1202d0954]
   5 exc_dispatch_exception(0x3ff804ea3d0, 0x11fffec80, 0x1200c232c,
0x3ffc008c750, 0x0) [0x1202cfd94]
   6 exc_raise_signal_exception(0x2000, 0x0, 0x0, 0x0, 0x0)
[0x3ffbfff13e0]
   7 getName(object = 0x202030206e6f6974, name = 0x2020202020202020 = "
can't read from process (address 0x2020202020202020)

Does anybody have an idea of what's going on here ? In particular,
I can't figure out what is Thread 0xfffffc0004568640 is and why it
comes to call __kill ?

Thank you for your attention,

Xav

T.R Title User Personal
Name Date Lines

9742.1 It's an unhandled exception caused by a memory corruption WTFN::SCALES Despair is appropriate and inevitable. Wed May 07 1997 13:11 28

T.R	Title	User	Personal Name	Date	Lines
9742.1	It's an unhandled exception caused by a memory corruption	WTFN::SCALES	Despair is appropriate and inevitable.	`Wed May 07 1997 13:11`	28
	Hi, Xav, Why'd you post this here instead of in the DECthreads notesfile...? (:-) Thread 0xfffffc0004568640 is the victim of an unhandled exception. The propagation of the exception unwould the stack to the base, at which point it was clear that the exception was not handled by the application code and DECthreads called kill() to abort the process. (I'm not sure why it appears that the process was killed by a SIGTRAP, but...) If you look carefully, you'll notice that the second thread is about to raise an exception also, as a result of a signal being delivered to it. (The exception code is serialized so that only one exception can be propagated at a time.) As for what's going on, it ought to be easy to determine if the problem is reproduceable: run the program under the debugger and catch all the signals; when the program stops, see why it received the signal. The following is pretty suspicious, though: .16> 7 getName(object = 0x202030206e6f6974, name = 0x2020202020202020 = " .16> can't read from process (address 0x2020202020202020) It would appear that someone has written space characters all over "name" and a quarter of "object" -- that would result in a nice SEGV! Webb

Hi, Xav,

Why'd you post this here instead of in the DECthreads notesfile...?  (:-)

Thread 0xfffffc0004568640 is the victim of an unhandled exception.  The
propagation of the exception unwould the stack to the base, at which point it
was clear that the exception was not handled by the application code and
DECthreads called kill() to abort the process.  (I'm not sure why it appears
that the process was killed by a SIGTRAP, but...)

If you look carefully, you'll notice that the second thread is about to raise
an exception also, as a result of a signal being delivered to it.  (The
exception code is serialized so that only one exception can be propagated at
a time.)

As for what's going on, it ought to be easy to determine if the problem is
reproduceable:  run the program under the debugger and catch all the signals;
when the program stops, see why it received the signal.  The following is
pretty suspicious, though:

.16>   7 getName(object = 0x202030206e6f6974, name = 0x2020202020202020 = "
.16> can't read from process (address 0x2020202020202020)

It would appear that someone has written space characters all over "name" and
a quarter of "object" -- that would result in a nice SEGV!


					Webb