aboutsummaryrefslogtreecommitdiffstats
path: root/lib/debugger/src
AgeCommit message (Collapse)Author
2011-11-09Fix "OK" spelling in debugger messages and variablesRicardo Catalinas Jiménez
Simple code refactor in the debugger: renames all the occurrences of "Ok" to "OK" in the code, variable names and strings. This improves the consistency of the code and follows the GTK UI where "OK" is always used.
2011-11-09Fix debugger message with wxRicardo Catalinas Jiménez
Add missing spaces when using wx UI. The gs UI didn't need them. Change the exclamation of the message by a dot, more formal style for a UI message.
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: By default, only save non-tail-recursive callsBjörn Gustavsson
By default, the debugger use to save all calls on its simulated stack. That could facilitate finding errors, but it could also mean that the Debugger could become very slow while executing tail-recursive code.
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-16Remove support for very old BEAM filesBjörn Gustavsson
Since the run-time system cannot load those BEAM files, it was not possible to debug them anyway.
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-16Fix handling of guard BIFs in list and binary comprehensionsBjörn Gustavsson
In a list comprehension, a failing call to a guard BIF means false (rather than an exception).
2011-08-16Handle terms in the top-level of guards properlyBjörn Gustavsson
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.
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-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
2011-08-16dbg_iload: Remove unnecessary handling of old guard testsBjörn Gustavsson
sys_pre_expand has already rewritten old guard tests to new guard tests.
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 BIFs that no longer exist from dbg_iload:bif_type/1Björn Gustavsson
2011-08-16Handle all guard BIFs as safe in function bodiesBjörn Gustavsson
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.)
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-07-06Remove deprecated concat_binary/1Björn Gustavsson
concat_binary/1 was deprecated in R13B04, but already in the R10B-2 release, the documentation recommends using list_to_binary/1 instead.
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2011-03-02Fix debugger warningsDan Gudmundsson
2010-09-10Remove warnings for clashes with new autoimported BIFsPatrik Nyblom
2010-07-07Merge branch 'ks/cleanups' into devRaimo Niskanen
* 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
2010-06-08Merge branch 'ks/ets-tid-type' into devErlang/OTP
* 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.
2010-06-07Remove tid() from the predefined builtin types.Kostis Sagonas
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.
2010-06-07debugger: Clean up as suggested by tidierKostis Sagonas
2010-06-03Merge branch 'pan/otp_8579_autoimport_override' into devErlang/OTP
* 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.
2010-06-02Remove (harmless) warnings about min/max in core applicationsPatrik Nyblom
2010-01-11Merge branch 'dgud/dbg_mac_menu' into ccase/r13b04_devErlang/OTP
* dgud/dbg_mac_menu: Dbg: Expand the module listbox when window grows. Dbg: Cut variable bindings after 80 chars. Dbg: Fixed documentation links to the new index.html Dbg Fixed mac gui issues OTP-8346 Miscellaneous corrections of the WX version of the debugger.
2009-12-18Dbg: Expand the module listbox when window grows.Dan Gudmundsson
2009-12-18Dbg: Cut variable bindings after 80 chars.Dan Gudmundsson
This is an optimization to avoid sending huge terms to the gui just to step by them and update variables again. Even better would be to only update if necessary.
2009-12-18Dbg: Fixed documentation links to the new index.htmlDan Gudmundsson
2009-12-18Dbg Fixed mac gui issuesDan Gudmundsson
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