| Age | Commit message (Collapse) | Author |
|---|
|
'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).
|
|
|
|
A long time ago, test suites were copied from other applications.
Copy the tests again to get more test cases.
|
|
In a list comprehension, a failing call to a guard BIF means
false (rather than an exception).
|
|
Expressions in guards such as:
f() when [1,2,3] ->
ok.
would cause the debugger to crash when attempting to interpret the
module containing the expressions. Other kind of constants such as:
f() when 42 ->
ok.
were converted to an invalid internal format ({integer,Line,42}
instead of {value,Line,42}), but that happened to work because
because anything not equal to 'true' (even a crash) was interpreted
as 'false'.
Make sure to handle all possible expressions and convert them
directly to {value,Line,false}. Remove the special handling of
the atom 'true' in and_guard/1 since it is no longer needed.
|
|
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.
|
|
|
|
|
|
sys_pre_expand has already rewritten old guard tests to
new guard tests.
|
|
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.
|
|
|
|
Make sure that all guards BIFs are handled as safe BIFs in function
bodies. BIFs in guards are already handled as safe. (self/0 is not
safe, but it is already specially handled.)
|
|
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.
|
|
concat_binary/1 was deprecated in R13B04, but already in
the R10B-2 release, the documentation recommends using
list_to_binary/1 instead.
|
|
|
|
* hw/call-chmod-without-f:
Call chmod without the "-f" flag
Conflicts:
erts/emulator/test/Makefile
lib/asn1/test/Makefile
lib/crypto/test/Makefile
lib/debugger/test/Makefile
lib/docbuilder/test/Makefile
lib/edoc/test/Makefile
lib/erl_interface/test/Makefile
lib/inviso/test/Makefile
lib/parsetools/test/Makefile
lib/percept/test/Makefile
lib/ssl/test/Makefile
lib/syntax_tools/test/Makefile
lib/test_server/test/Makefile
lib/tools/test/Makefile
OTP-9170
|
|
bmk/inets/ftp/missing_spec_causes_dialyxer_problems/OTP-9114
Also fixed a bunch of "end-years" (was 2010 but should have been 2011,
which the commit hook not happy with).
|
|
|
|
|
|
OTP-9107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"-f" is a non-standard chmod option which at least SGI IRIX and HP UX do
not support. As the only effect of the "-f" flag is to suppress warning
messages, it can be safely omitted.
|
|
|
|
|
|
* maint-r13:
Add test suite for ic
Add test suite for runtime_tools
Add test suite for debugger
Add test suite for os_mon
|
|
|
|
* ks/cleanups:
compiler: Fix incorrect types and specs
escript: Add more types to records
debugger: Clean up as suggested by tidier
docbuilder: Clean up as suggested by tidier
Conflicts:
lib/debugger/src/dbg_iload.erl
lib/debugger/src/dbg_ui_trace_win.erl
|
|
|
|
|
|
* ks/ets-tid-type:
Remove tid() from the predefined builtin types.
OTP-8687 ks/ets-tid-type
The predefined builtin type tid() has been removed. Instead, ets:tid()
should be used.
|
|
Change erl_lint not to recognize this type as builtin and
add a new erl_lint.beam version in bootstrap.
Add an -opaque type declaration for this type in ets.erl
and also declare this as an exported type. Use this type
in file debugger/src/dbg_iload.erl in a spec.
While at it, also clean up this later file a bit.
|
|
|
|
* origin/pan/otp_8579_autoimport_override:
Update preloaded modules
Update primary bootstrap
Remove outcommented code from erl_lint
Make port_command/3 auto-imported
Remove (harmless) warnings about min/max in core applications
Autoimport min/2 and max/2
Improve coverage of erl_int in testcases
Change warning to error for nowarn_bif_clash compiler directive
Add -compile({no_auto_import,[F/A]}) doc to compiler.xml
Add some testcases to compiler to verify that overriding really happens
Return nowarn_bif_clash functionality but with warning
Teach erl_lint to better override BIFs with local functions and imports
Teach compiler to override autoimport with import
First prototype for local functions overriding autoimported
OTP-8579 Local functions should override auto-imported
Local and imported functions now override the autoimported
BIFs when the names clash. The pre R14 behaviour was that
autoimported BIFs would override local functions. To avoid
that old programs change behaviour, the following will
generate an error:
Doing a call without explicit module name to a local function
having a name clashing with the name of an autoimported BIF
that was present (and autoimported) before OTP R14A
Explicitly importing a function having a name clashing with
the name of an autoimported BIF that was present (and
autoimported) before OTP R14A Using any form of the old
compiler directive nowarn_bif_clash
If the BIF was added or autoimported in OTP R14A or later,
overriding it with an import or a local function will only
result in a warning,
To resolve clashes, you can either use the explicit module
name erlang to call the BIF, or you can remove the autoimport
of that specific BIF by using the new compiler directive
-compile({no_auto_import,[F/A]})., which makes all calls to
the local or imported function without explicit module name
pass without warnings or errors.
The change makes it possible to add autoimported BIFs without
breaking or silently changing old code in the future. However
some current code ingeniously utilizing the old behaviour or
the nowarn_bif_clash compiler directive, might need changing
to be accepted by the compiler.
|
