When an ASB 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 ASB 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 will 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.
See Also
History
2012 December, A-Shell 6.1.1325: Feature added to A-Shell
