aboutsummaryrefslogtreecommitdiffstats
path: root/lib/debugger/src/dbg_istk.erl
AgeCommit message (Collapse)Author
2011-08-18debugger: Include line numbers in exceptionsBjörn Gustavsson
2011-08-16emulator: Add a fourth element in exception stacktracesBjörn Gustavsson
This commit is a preparation for introducing location information (filename/line number) in stacktraces in exceptions. Currently a stack trace looks like: [{Mod1,Function1,Arity1}, . . . {ModN,FunctionN,ArityN}] Add a forth element to each tuple that can be used indication the filename and line number of the source file: [{Mod1,Function1,Arity1,Location1}, . . . {ModN,FunctionN,ArityN,LocationN}] In this commit, the fourth element will just be an empty list, and we will change all code that look at or manipulate stacktraces.
2011-08-16Don't include tail-recursive calls in stacktracesBjörn Gustavsson
The stacktrace in debugger-generated exceptions should be as similar to stacktraces in BEAM-generated exceptions as possible.
2011-08-16Fix the no_tail optionBjörn Gustavsson
The 'no_tail' option was broken and would work almost as the 'all' option, because it would use #ieval.top (formerly known as #ieval.last_call) as the basis for its decision to push or not. Fix it by including a boolean in each call/apply instruction indicating whether the call is tail-recursive and pass that boolean to the dbg_istk:push() function.
2011-08-16Delay saving of the stack in exit_info when an exception occursBjörn Gustavsson
When an exception occurs, the entire stack will be converted to the external term format and kept in the exit_info variable in the process dictionary. But the exit_info variable will only be needed if the exception causes the process to terminate (not if it is caught). Delay the conversion of the stack to external format. That can save significant amounts of time (e.g. in bs_construct:mem_leak/1).
2011-08-16Make stacktraces in exceptions more similar to BEAM's stacktracesBjörn Gustavsson
When an exception was generated from interpreted code, the stacktrace would not look exactly like BEAM's stacktraces. There would generally be fewer entries (never more than three), and the top entry would always have MFAs with the actual arguments (rather than the arity). There are two good reasons for making the stacktraces as similar as possible: * Code that examines a stacktrace can behave differently in the interpreted and BEAM code if the stacktraces are different. * It is easier to test the debugger if test suites for other applications (such as the emulator) can be run with the debugger with as few modifications as possible.
2011-08-16Don't build stacktrace until erlang:get_stacktrace() is calledBjörn Gustavsson
Currently, dbg_istk:exception_stacktrace/2 does not do a very good job imitating BEAM's stacktrace. The reason is that it need to be relatively fast since a simulated stacktrace is constructed not only when an exception oocurs, but also before every call to non-interpreted code. To prepare for a future more thorough (and slower) stacktrace construction, refactor the building of the stacktrace so that it only is done when erlang:get_stacktrace/0 is called.
2011-08-16Rewrite stack handlingBjörn Gustavsson
Problems with the current stack implementation: * The GUI assumes that the stack frame pushed on the stack is level 2. If the 'no_tail' option is set for the process, there may not be an entry for level 2. * In each stack entry, the line number is the line number of the caller, not the line number for the function in the 'mfa' field as might be expected. That complicates generation of a stacktrace with line number information. Change the implementation as follows: * Keep the information for the current function (its MFA and current line number) in the #ieval{} record. Don't push it onto the stack. Only push the information when another function is called. That will ensure that the MFA and the line number is found in the same stack entry. That also has the advantage that if the 'no_tail' option is set, the stack not need to be modified for tail-recursive calls. * Make sure that there always is an entry for level two.
2011-08-16ieval record: Rename the misnamed 'last_call' field to 'top'Björn Gustavsson
The 'last_call' is badly named. What is means is that the next call will leave intepreted code.
2011-08-16dbg_istk: Use a record for stack entries instead of a tupleBjörn Gustavsson
2011-08-16Break out stack handling into the dbg_istk moduleBjörn Gustavsson