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

Conference clt::cma

Title:	DECthreads Conference

Moderator:	PTHRED::MARYSTEON

Created:	Mon May 14 1990
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1553
Total number of notes:	9541

1549.0. "help understanding cma__error " by PANTER::MARTIN (Be vigilant...) Fri May 23 1997 11:43

    A customer has a problem with an application he's writing.
    
    The problem core dumps with the following error, I advised
    the customer to install the latest and greatest Digital Unix
    v3.2c patches (all) to see if it improves, but can someone
    give a more rationnal explanation of what the problem can
    be ?
    
    What looks odd to me is the fact the stack trace shows up
    an unknown function in the stack trace just before entering
    into the cma__error function :
    
    Thanks in advance,
    				============================
    				Alain MARTIN/SSG Switzerland
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    
    
alpha>dbx srvsql.exe core 
dbx version 3.11.8 
Type 'help' for help. 
Core file created by program "srvsql.exe" 

signal Segmentation fault at >*[__kill, 0x120224ba8]    beq     r19, 0x120224bc0 
(dbx) where 
>  0 __kill(0xb, 0x0, 0x0, 0x0, 0x0) [0x120224ba8] 
   1 exc_raise(0x11fffd2d0, 0x2, 0x0, 0x1400f4270, 0x0) [0x1201f561c] 
   2 exc_raise_status(0x45586732, 0x2, 0x0, 0x0, 0x0) [0x1201f5778] 
   3 cma__error(0x0, 0x0, 0x0, 0x1, 0x120211108) [0x1201f5434] 
   4 (unknown)(0x0, 0x3530373930323345, 0x11fffd3b8, 0x0, 0x59) [0x120211104] 
   5 _tmgrefind(0x0, 0x3fffffe9500, 0x1400011e8, 0x140001200, 0x3ffbffa6544) ["] 
   6 _tmtran_reattach(0x1400011e8, 0x140001200, 0x3ffbffa6544, 0x0, 0x3ffbff75c] 
   7 _tmreattach(0x3ffbffa6544, 0x0, 0x3ffbff75cec, 0x45828, 0x3ffbff6a320) ["t] 
   8 _tmatmienter(0x0, 0x0, 0x0, 0x0, 0x0) ["tmenter.c":76, 0x3ffbff6a31c] 
   9 tpreturn(0x4000000, 0x0, 0x14170, 0x0, 0x0) ["tmreturn.c":83, 0x3ffbff76ec] 
  10 nytux_tpreturn(0x1, 0x2, 0x4000000, 0x0, 0x11fffd9a8) [0x12018a8d4] 
  11 NYDBA_SQL_BATCH(msg = 0x3fffffe9270) ["/stelink/v2.2/source/ny/dba/source/] 
  12 _tmsvcdsp(0xcde00338455a7, 0x0, 0x3ffbff8d64c, 0x458a8, 0x1) ["tmsvcdsp.c"] 
  13 _tmrunserver(0x0, 0x11fffdfe8, 0x120033248, 0x2000, 0x1200332b0) ["tmrunsv] 
  14 main(0x10, 0x11fffdfe8, 0x120033168, 0x8f96b, 0x100000000) [0x1200332fc] 
More (n if no)? 
(dbx)
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

T.R Title User Personal
Name Date Lines

1549.1 Same old same old -- the exception has unwound the stack. WTFN::SCALES Despair is appropriate and inevitable. Fri May 23 1997 12:19 28

T.R	Title	User	Personal Name	Date	Lines
1549.1	Same old same old -- the exception has unwound the stack.	WTFN::SCALES	Despair is appropriate and inevitable.	`Fri May 23 1997 12:19`	28
	.0> A customer has a problem with an application he's writing. I expect that the problem is that there is a segmentation violation in some subroutine called by _tmgrefind() inside a TRY block (or in a region portected by a Pthread clean-up handler). The SEGV is converted to an exception which propagates up the frames of the stack, unwinding as it goes, until it reaches the _tmgrefind() frame. The TRY block in this frame, however, doesn't have a CATCH for SEGV (and it either has no CATCH_ALL or it has a FINALLY; or it is a Pthread clean-up handler rather than a TRY block), and so the exception is reraised. However, at this point, there are no more TRY blocks or Pthread clean-up handlers in frames up the stack, and so DECthreads terminates the process, since the exception is now "unhandled", by converting the exception back into the original signal. Since this application is under active development (you said the customer is "writing" it), it should be straightforward for the customer to run it under control of the debugger (either directly or by attaching to it). If the customer catches SIGSEGV in the debugger, he should be able to find the exact source of the segmentation violation in his application. .0> What looks odd to me is the fact the stack trace shows up an unknown .0> function in the stack trace I don't think this is particularly odd -- I've often seen the debugger use this form whenever there's a "call through a pointer". Webb

.0> A customer has a problem with an application he's writing.

I expect that the problem is that there is a segmentation violation in some
subroutine called by _tmgrefind() inside a TRY block (or in a region
portected by a Pthread clean-up handler).  The SEGV is converted to an
exception which propagates up the frames of the stack, unwinding as it goes,
until it reaches the _tmgrefind() frame.  The TRY block in this frame,
however, doesn't have a CATCH for SEGV (and it either has no CATCH_ALL or it
has a FINALLY; or it is a Pthread clean-up handler rather than a TRY block),
and so the exception is reraised.  However, at this point, there are no more
TRY blocks or Pthread clean-up handlers in frames up the stack, and so
DECthreads terminates the process, since the exception is now "unhandled", by
converting the exception back into the original signal.

Since this application is under active development (you said the customer is
"writing" it), it should be straightforward for the customer to run it under
control of the debugger (either directly or by attaching to it).  If the
customer catches SIGSEGV in the debugger, he should be able to find the exact
source of the segmentation violation in his application.

.0> What looks odd to me is the fact the stack trace shows up an unknown
.0> function in the stack trace

I don't think this is particularly odd -- I've often seen the debugger use
this form whenever there's a "call through a pointer".


				Webb