| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Prior to this change, calls inside binaries were
treated as top level which would cause the `Fun(Arg)`
call inside `<<Fun(Arg)/binary>>` to return an internal
dbg_ieval tuple and ultimately error with badarg.
|
|
|
|
|
|
|
|
|
|
|
|
Make sure that we recognize map literals at load time, as we
do for lists and tuples. Also use maps:from_list/1 to build
a new map instead of building it up from scratch inserting one
key/value pair at the time.
|
|
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
The ct_line module was removed some releases ago.
|
|
Reported-by: José Valim
|
|
|
|
* nox/debugger/erl_eval_SUITE/OTP-11676:
Truly test debugger in erl_eval_SUITE copy
|
|
The module was not interpreted.
This surfaced two bugs, related to shadowed variables in binary patterns in
comprehension generators, and guard filters not properly detected. The guard
detection code from dbg_iload is deleted in favor of erl_lint:is_guard_test/1.
The erl_lint module is now safe to use because it can handle all expressions
emitted by sys_pre_expand, the following warning is thus obsolete and has been
removed from code:
%% Cannot use erl_lint here as sys_pre_expand has transformed source.
|
|
* vladdu/debugger/fixes:
remove warning for variable exported from case
remove useless match
remove unused parameter
|
|
|
|
A test is commented-out in map_SUITE:t_update_exact/1, waiting for a fixed
maps:update/3 function with correct integer/float semantics.
|
|
* nox/fix-dbg_ieval-exporting-rules/OTP-11553:
compiler tests: Test exporting rules for andalso/orelse
Fix evaluation of andalso and orelse in the debugger
|
|
Their exporting rules were not respected.
|
|
The current code for the evaluation of ordinary funs is dependent
on the order on variables in the fun environment as returned by
erlang:fun_info(Fun, env). As it happened, adding the code for
named funs changed the order in the environment for ordinary funs.
To avoid the problem in the future, make sure that we only have one
free variable in the funs that we will need to inspect using
erlang:fun_info(Fun, env).
|
|
A new checkbox has been added. When it is checked, the range set by
the 'erl' flag '+pc' is used for determining when to print lists of
integers as strings. When it is unchecked, integer lists are never
printed as strings.
A minor incompatibility: settings saved by Erlang R16B01
or later cannot be read by Erlang R16B or earlier.
|
|
|
|
Bindings in erl_eval is an orddict and must be sorted otherwise
they are not found, depending on creation order
|
|
|
|
Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".
In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).
EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.
Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.
We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.
Reference: http://www.erlang.org/eeps/eep-0023.html
|
|
|
|
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.
|
|
An exception from eval_bits:expr_grp/5 (for constructing binaries)
was not caught and handled by exception/4; thus exit_info and
and stacktrace for the process was not set.
|
|
'eval_bits' is a common utility module used for evaluting binary
construction and matching. The functions that do matching
(match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as
an abstract data type, but they assume that the bindings have the same
representation as in the erl_eval module. That may cause binary
matching to fail in the debugger, because the debugger represents the
bindings as an unordered list of two-tuples, while the erl_eval
modules uses an ordered list of two-tuple (an ordset).
One way to fix the problem would be to let the debugger to use ordered
lists to represent the bindings. Unfortunately, that would also change
how the bindings are presented in the user interface. Currently, the
variable have most been recently assigned is shown first, which is
convenient.
Fix the matching problem by mending the leaky abstraction in
eval_bits. The matching functions needs to be passed two additional
operations: one for looking up a variable in the bindings and one for
adding a binding. Those operations could be passed as two more funs
(in addition to the evaluation and match fun already passed), but the
functions already have too many arguments. Therefore, change the
meaning of the match fun, so that the first argument is the operation
to perform ('match', 'binding', or 'add_binding') and second argument
is a tuple with arguments for the operation.
|
|
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).
|
|
erlang:raise/3 was evaluated in the real process, which produced
a correct stacktrace, but did not set emulated stacktrace for the
process. Thus, a subsequent call to erlang:get_stacktrace/0 would
retrieve the previous stacktrace for the process.
|
|
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.
|
|
There is no need to set #ieval.top to false in every
iteration of eval_list/1.
|
|
The 'last_call' is badly named. What is means is that the
next call will leave intepreted code.
|
|
|
|
Many releases ago, Mod:module_info/{0,1} used to be specially
handled in the BEAM loader. The debugger has similar special
handling.
In the current implementation, Mod:module_info/{0,1} are ordinary
functions that call special BIFs to do their work.
Therefore, remove the special handling of Mod:module_info/{0,1}
in the debugger.
|
|
BIFs that spawn new processes once upon a time needed/benefited
from special handling, but now they are handled in exactly the
same way as an unsafe BIF (except for a bug in the handling of
the return value trace). Therefore, treat spawn BIFs as unsafe
BIFs.
|
|
Since erlang:fault/{1,2} is no longer supported in the run-time
system (it was removed several releases ago), there is no need
to still support it in the debugger.
|
|
|
|
|
|
short-circuit expressions in guards.
|
|
|
