Call Stack Tracing

Added December 2012

When a Basic error occurs and the system trace opcode BASERR is set, details about the error will be automatically logged to the ashlog.log file. For example:

04-Dec-12 14:36:50 [JACKX201:02-2]<TEST1:UTIL99> Trapped Basic Error #10 at location counter 11219

04-Dec-12 14:36:50 [JACKX201:02-2]<TEST1:UTIL99> Call stack trace, from program TEST1 :

From loc 494, Xcall UTIL99

From loc f42d, Call Proc() @f5d6

From loc fc85, Call Proc() @10d37

The first line indicates that the error #10 occurred at location 11219 (hex) in UTIL99.SBX which was called by TEST1; and that it was trapped.

As of A-Shell 6.1.1325, if the error occurs anywhere but the main body of the main program, a call stack trace will be shown as well, so as to help you identify how the program got to where the error occurred. For deeply nested errors, this can be a significant aid to debugging. The above stack trace starts out in program TEST1, location 494 (hex), where there is a subroutine UTIL99. Next, at location f42d within UTIL99.SBX, there is a call to procedure whose address is 5fd6. You'll need to use the LSX file to look up that location to determine the name of the procedure. Similarly, from within that procedure, there is another procedure call at location fc85, to a procedure whose address is 10d37.

Under UNIX, the call stack trace will also be logged in the case of segmentation fault (which should be a rare occurrence, but when it does happen, the stack trace is invaluable since there's no way to trap the error before the entire process is terminated.