Age | Commit message (Collapse) | Author | |
---|---|---|---|
2018-06-18 | Update copyright year | Henrik Nord | |
2018-01-22 | Don't build a stacktrace if it's only passed to erlang:raise/3 | Björn Gustavsson | |
Consider the following function: function({function,Name,Arity,CLabel,Is0}, Lc0) -> try %% Optimize the code for the function. catch Class:Error:Stack -> io:format("Function: ~w/~w\n", [Name,Arity]), erlang:raise(Class, Error, Stack) end. The stacktrace is retrieved, but it is only used in the call to erlang:raise/3. There is no need to build a stacktrace in this function. We can avoid the building if we introduce an instruction called raw_raise/3 that works exactly like the erlang:raise/3 BIF except that its third argument must be a raw stacktrace. | |||
2017-11-30 | Add syntax in try/catch to retrieve the stacktrace directly | Björn Gustavsson | |
This commit adds a new syntax for retrieving the stacktrace without calling erlang:get_stacktrace/0. That allow us to deprecate erlang:get_stacktrace/0 and ultimately remove it. The problem with erlang:get_stacktrace/0 is that it can keep huge terms in a process for an indefinite time after an exception. The stacktrace can be huge after a 'function_clause' exception or a failed call to a BIF or operator, because the arguments for the call will be included in the stacktrace. For example: 1> catch abs(lists:seq(1, 1000)). {'EXIT',{badarg,[{erlang,abs, [[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20|...]], []}, {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]}, {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]}, {shell,exprs,7,[{file,"shell.erl"},{line,687}]}, {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]}, {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]}} 2> erlang:get_stacktrace(). [{erlang,abs, [[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, 23,24|...]], []}, {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]}, {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]}, {shell,exprs,7,[{file,"shell.erl"},{line,687}]}, {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]}, {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}] 3> We can extend the syntax for clauses in try/catch to optionally bind the stacktrace to a variable. Here is an example using the current syntax: try Expr catch C:E -> Stk = erlang:get_stacktrace(), . . . In the new syntax, it would look like: try Expr catch C:E:Stk -> . . . Only a variable (not a pattern) is allowed in the stacktrace position, to discourage matching of the stacktrace. (Matching would also be expensive, because the raw format of the stacktrace would have to be converted to the cooked form before matching.) Note that: try Expr catch E -> . . . is a shorthand for: try Expr catch throw:E -> . . . If the stacktrace is to be retrieved for a throw, the 'throw:' prefix must be explicitly included: try Expr catch throw:E:Stk -> . . . | |||
2017-07-07 | Add stacktrace entries to BIF calls from emulator | José Valim | |
The goal of this change is to improve debugging of emulator calls. For example, the following code rem(1, y) will error with atom `badarith` when y is 0 and the stacktrace has no entry for `erlang:rem/2`, making such cases very hard to debug. This patch makes it so the stacktrace includes `erlang:rem(1, 0)`. The following emulator BIFs have been changed: * band/2 * bnot/1 * bor/2 * bsl/2 * bsr/2 * bxor/2 * div/2 * element/2 * int_div/2 * rem/2 * sminus/2 * splus/2 * stimes/2 | |||
2016-05-13 | trycatch_SUITE: Cover the only uncovered line in sys_core_fold | Björn Gustavsson | |
Recent spring cleaning in the test suite left a line in sys_core_fold dealing with an unnecessary catch uncovered. | |||
2016-04-27 | Move catch tests to trycatch_SUITE | Björn Gustavsson | |
2016-03-15 | update copyright-year | Henrik Nord | |
2016-02-25 | Remove ?line macros | Björn Gustavsson | |
2016-02-17 | Eliminate use of test_server.hrl and test_server_line.hrl | Björn Gustavsson | |
As a first step to removing the test_server application as as its own separate application, change the inclusion of test_server.hrl to an inclusion of ct.hrl and remove the inclusion of test_server_line.hrl. | |||
2015-06-18 | Change license text to APLv2 | Bruce Yinhe | |
2015-02-20 | beam_jump: Don't jump into the middle of a 'try' | Björn Gustavsson | |
The code sharing optimization could produce a jump into the middle of a 'try' block. beam_validator would reject the code. Reported-by: Ulf Norell | |||
2015-02-03 | sys_core_fold: Optimize let statements more aggressively | Björn Gustavsson | |
I originally decided that in 'value' context, rewriting a let statement where the variables were not in the body to a sequence was not worth it, because the variables would be unused in only one let in a thousand lets (roughly). I have reconsidered. The main reason is that if we do the rewrite, core_lib:is_var_used/2 will be used much more frequently, which will help us to find bugs in it sooner. Another reason is that the way letify/2 is currently implemented with its own calls to core_lib:is_var_used/2 is only safe as long as all the bindings are independent of each other. We could make letify/2 smarter, but if we introduce this new optimization there is no need. Measuring compilation speed, I have not seen any significant slowdown. It seems that although core_lib:is_var_used/2 is called much more frequently, most calls will be fast because is_var_used/2 will quickly find a use of the variable. Also add a test case to cover a line opt_guard_try/1 that was no longer covered. | |||
2015-01-26 | Speed up running of compiler test suites in coverage mode | Björn Gustavsson | |
I have spent too much time lately waiting for 'cover' to finish, so now its time to optimize the running time of the tests suite in coverage mode. Basically, when 'cover' is running, the test suites would not run any tests in parallel. The reason is that using too many parallel processes when running 'cover' would be slower than running them sequentially. But those measurements were made several years ago, and many improvements have been made to improve the parallelism of the run-time system. Experimenting with the test_lib:p_run/2 function, I found that increasing the number of parallel processes would speed up the self_compile tests cases in compilation_SUITE. The difference between using 3 processes or 4 processes was slight, though, so it seems that we should not use more than 4 processes when running 'cover'. We don't want to change test_lib:parallel/0, because there is no way to limit the number of test cases that will be run in parallel by common_test. However, there as test suites (such as andor_SUITE) that don't invoke the compiler at run-time. We can run the cases in such test suites in parallel even if 'cover' is running. | |||
2012-10-23 | compiler: Run testcases in parallel | Björn Gustavsson | |
Run testcases in parallel will make the test suite run slightly faster. Another reason for this change is that we want more testing of parallel testcase support in common_test. | |||
2012-03-30 | Update copyright years | Björn-Egil Dahlberg | |
2012-01-18 | compiler: Correct live calculation when get/1 is used in try...catch | Björn Gustavsson | |
In the following code excerpt, the instruction marked below was incorrectly removed: . . . {'try',{y,2},{f,TryCaseLabel}}. {bif,get,{f,0},[{x,0}],{x,0}}. {move,{x,1},{y,0}}. {move,{x,3},{y,1}}. <======= Incorrectly removed {jump,{f,TryEndLabel}}. {label,TryEndLabel}. {try_end,{y,2}}. {deallocate,3}. return. {label,TryCaseLabel}. {try_case,{y,2}}. . . . beam_utils indicated that {y,1} was not used at TryEndLabel, which by itself is correct. But it is still not safe to remove the instruction, because {y,1} might be used at TryCaseLabel if an exception occurs. Noticed-by: Eric Merritt | |||
2011-08-16 | emulator: Add a fourth element in exception stacktraces | Bjö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-04-12 | compiler tests: Reinstate ?MODULE macro in calls to test_lib:recompile/1 | Björn Gustavsson | |
In 3d0f4a3085f11389e5b22d10f96f0cbf08c9337f (an update to conform with common_test), in all test_lib:recompile(?MODULE) calls, ?MODULE was changed to the actual name of the module. That would cause test_lib:recompile/1 to compile the module with the incorrect compiler options in cloned modules such as record_no_opt_SUITE, causing worse coverage. | |||
2011-03-11 | Update copyright years | Björn-Egil Dahlberg | |
2011-02-17 | Rename Suite Callback to Common Test Hook | Lukas Larsson | |
2011-02-17 | Fix formatting for compiler | Lukas Larsson | |
2011-02-17 | Add init_per_suite and end_per_suite | Lukas Larsson | |
2011-02-17 | Add ts_install_scb to suite/0 | Lukas Larsson | |
2011-02-17 | Update compiler tests to conform with common_test standard | Lukas Larsson | |
2011-02-17 | Update all fin_per_testcase to end_per_testcase. | Lukas Larsson | |
2009-11-20 | The R13B03 release.OTP_R13B03 | Erlang/OTP | |