Download Firefox: WindowsMac OS X
logo       
Google Custom Search
    AddThis Social Bookmark Button

suppressing system frames in stack traces: msg#00004

Subject: suppressing system frames in stack traces
When inspecting stack traces, users are often only interested in
information pertaining to their own code, not library and sisc-internal
code.

In SISC 1.14 we introduced a stack marker that suppresses stack
information below the REPL's invocation of user code. This works
reasonably well but fails when the stack contains several transitions
between user and system code, for example as the result of user code
calling a system higher order function with a user-level function as the
parameter, e.g.

SISC (1.14.0-alpha)
#;> (map (lambda (x) (/ 1 x)) '(1 0 1))
Error in /: <java.lang.ArithmeticException>: division by zero.
---------------------------
console:1:18: <from call to />
file:init.scm:94:36: <indeterminate call>
---------------------------
file:init.scm:93:24: <indeterminate call>
file:init.scm:106:11: <indeterminate call>
console:1:1: <from call to map>
sisc.modules.Primitives/with-stack-marker:?:?: <indeterminate call>
#;> 


Instead the above should just say

#;> (map (lambda (x) (/ 1 x)) '(1 0 1))
Error in /: <java.lang.ArithmeticException>: division by zero.
---------------------------
console:1:18: <from call to />
---------------------------
console:1:1: <from call to map>
#;> 


Of course sometimes we *do* want to see the details of all the system
call. Hence we want the amount of information displayed to be
configurable.


I have been told that PLT Scheme accomplishes this by marking every
single function application expression with a special marker, indicating
whether it us user or system code. It does this via a program
transformation. Stack display code can then decide whether or not to
display stack elements that originated from expressions marked in a
certain way.


I'd rather avoid a program transformation, so here is an alternative
approach:

We introduce a dynamic parameter *SOURCE-KIND*. This is set to a value
like 'system, 'library or 'user, depending on the kind of code we are
processing. When source annotations are produced, an annotation
containing the current value of that parameter is added. Compilation
automatically propagates that to the produced micro expressions (as long
as emit-annotations is set to #t).

Stack tracing gets parameterised with a dynamic parameter
*SUPPRESSED-STACK-TRACK-SOURCE-KINDS* that contains a list of source
kinds to suppress in the stack trace. A #f element stands for "absent
source kind". A value of #f result in no source kinds being
suppressed. The default value is '(system library #f), meaning that all
frames with system, library or unknown source kind should be suppressed.


Can anybody think of improvements to the above, or a different scheme
altogether?



Matthias



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


<Prev in Thread] Current Thread [Next in Thread>