| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
The stacktrace in debugger-generated exceptions should be
as similar to stacktraces in BEAM-generated exceptions as
possible.
|
|
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.
|
|
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).
|
|
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.
|
|
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.
|
|
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.
|
|
The 'last_call' is badly named. What is means is that the
next call will leave intepreted code.
|
|
|
|
|
