aboutsummaryrefslogtreecommitdiffstats
path: root/lib/debugger/src/dbg_ieval.erl
AgeCommit message (Collapse)Author
2016-02-17debugger: Add suppression of Dialyzer warningsHans Bolinder
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30debugger: Optimize evaluation of new map creationBjörn Gustavsson
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.
2015-04-30debugger: Use module erl_annoHans Bolinder
2015-04-15Raise more descriptive error messages for failed map operationsBjörn Gustavsson
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.
2014-10-21debugger: clean up Common Test adaptionHans Bolinder
The ct_line module was removed some releases ago.
2014-05-03Fix evaluation of map updates in the debugger and erl_evalAnthony Ramine
Reported-by: José Valim
2014-03-15Fix evaluation of empty map updates in the debuggerAnthony Ramine
2014-02-10Merge branch 'nox/debugger/erl_eval_SUITE/OTP-11676'Björn Gustavsson
* nox/debugger/erl_eval_SUITE/OTP-11676: Truly test debugger in erl_eval_SUITE copy
2014-02-10Truly test debugger in erl_eval_SUITE copyAnthony Ramine
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.
2014-02-07Merge branch 'vladdu/debugger/fixes'Björn Gustavsson
* vladdu/debugger/fixes: remove warning for variable exported from case remove useless match remove unused parameter
2014-02-05remove warning for variable exported from caseVlad Dumitrescu
2014-02-04Support maps in the debuggerAnthony Ramine
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.
2014-01-09Merge branch 'nox/fix-dbg_ieval-exporting-rules/OTP-11553'Björn Gustavsson
* 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
2013-12-15Fix evaluation of andalso and orelse in the debuggerAnthony Ramine
Their exporting rules were not respected.
2013-12-12Support named funs in the debugger interpreterAnthony Ramine
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).
2013-03-07[debugger] Add an option 'Strings'Hans Bolinder
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.
2013-01-25Make adjustments for UnicodeHans Bolinder
2013-01-10debugger: Fix user evalution dependent of bindings in trace windowDan Gudmundsson
Bindings in erl_eval is an orddict and must be sorted otherwise they are not found, depending on creation order
2013-01-09Prepare OTP files for Unicode as default encodingHans Bolinder
2011-11-07EEP-23: Allow variables in fun M:F/ABjörn Gustavsson
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
2011-08-18debugger: Include line numbers in exceptionsBjörn Gustavsson
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-16dbg_ieval: Properly handle exceptions when binary construction failsBjörn Gustavsson
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.
2011-08-16Fix binary matching in the debuggerBjörn Gustavsson
'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.
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 sure that erlang:raise/3 sets the emulated stacktraceBjörn Gustavsson
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.
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-16Slightly clean-up and optimize some evaluation codeBjörn Gustavsson
There is no need to set #ieval.top to false in every iteration of eval_list/1.
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-16Break out stack handling into the dbg_istk moduleBjörn Gustavsson
2011-08-16Remove the special handling of Mod:module_info/{0,1}Björn Gustavsson
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.
2011-08-16Remove the special handling of spawn BIFsBjörn Gustavsson
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.
2011-08-16Remove support for erlang:fault/{1,2}Björn Gustavsson
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.
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2010-06-07debugger: Clean up as suggested by tidierKostis Sagonas
2009-12-01OTP-8310 Bugs have been fixed in the evaluation of comprehensions andHans Bolinder
short-circuit expressions in guards.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP