aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/beam_validator.erl
AgeCommit message (Collapse)Author
2018-08-22beam_validator: Infer the type of the map argument for is_map_key/2Björn Gustavsson
Make sure that beam_validator considers a call to is_map_key/2 followed by an update of the same map without an is_map/1 test safe. (This situation will probably not be encountered when using the compiler in OTP 21, but better safe than sorry.)
2018-08-06beam_validator: Fix false diagnostic for a receive nested in a tryBjörn Gustavsson
When nesting a receive in a try/catch, there could be a false diagnostic that a fragile term is used. https://bugs.erlang.org/browse/ERL-684
2018-06-27Fix internal compiler error for map_get/2Björn Gustavsson
Code such as that the following: Val = map_get(a, Map), Map#{a:=z} %Could be any map update would incorrectly cause an internal consistency check failure: Internal consistency check failed - please report this bug. Instruction: {put_map_exact,{f,0},{x,0},{x,0},1,{list,[{atom,a},{atom,z}]}} Error: {bad_type,{needed,map},{actual,term}}: Update beam_validator so that it understands that the second argument for map_get/2 is a map.
2018-06-18Update copyright yearHenrik Nord
2018-04-27beam_validator: Verify Y registers in exception-causing instructionsBjörn Gustavsson
When an exception is handled, the stack will be scanned. Therefore all Y registers must be initialized.
2018-04-25beam_validator: Clear X registers in wait_timeoutBjörn Gustavsson
Help us find more compiler bugs.
2018-04-11beam_validator: Remove repeated "this"Björn Gustavsson
2018-04-11beam_validator: Remove unnecessary inclusion of beam_disasm.hrlBjörn Gustavsson
2018-04-11beam_validator: Strengthen validation of remaining GC instructionsBjörn Gustavsson
1ee21858db7e strengenthed validatation of GC instructions, but forgot the following instructions: bs_start_match2/5 bs_get_binary2/7 bs_get_float2/7 bs_get_integer2/7 bs_get_utf8/5 bs_get_utf16/5 bs_get_utf32/5 bs_skip_utf8/4 bs_skip_utf16/4 bs_skip_utf32/4
2018-04-06Check that messages outside of the heap are not corruptedBjörn Gustavsson
Waiting messages for a process may be stored in a queue outside of any heap or heap fragment belonging to the process. This is an optimization added in a recent major release to avoid garbage collection messages again and again if there is a long message queue. Until such message has been matched and accepted by the remove_message/0 instruction, the message must not be included in the root set for a garbage collection, as that would corrupt the message. The loop_rec/2 instruction explicitly turns off garbage collection of the process as long messages are being matched. However, if the compiler were to put references to a message outside of the heap in an Y register (on the stack) and there happened to be a GC when the process had been scheduled out, the message would be corrupted and the runtime system would crash sooner or later. To ensure that doesn't happen, teach beam_validator to check for references on the stack to messages outside of the heap.
2018-03-01Enhance beam_validator to check proper nesting of try/catch and catchBjörn Gustavsson
Every catch or try/catch must use a lower Y register number than any enclosing catch or try/catch. That will ensure that when the stack is scanned when an exception occurs, the innermost try/catch tag is found first.
2018-02-14Merge branch 'maint'Björn Gustavsson
* maint: Check that the stack is initialized when an exception may occur
2018-02-09Check that the stack is initialized when an exception may occurBjörn Gustavsson
Strengthen beam_validator to check that the stack is initialized when an instruction with an {f,0} operand is executed. For example, the following code sequence: {allocate,0,1}. {bif,element,{f,0},[{integer,1},{x,0}],{x,0}}. should not be accepted because the stack may be scanned if element/2 fails. That could cause a crash or other undefined behavior if garbage on the stack looks like a catch tag.
2018-01-26Eliminate get_list/3 internally in the compilerBjörn Gustavsson
Instructions that produce more than one result complicate optimizations. get_list/3 is one of two instructions that produce multiple results (get_map_elements/3 is the other). Introduce the get_hd/2 and get_tl/2 instructions that return the head and tail of a cons cell, respectively, and use it internally in all optimization passes. For efficiency, we still want to use get_list/3 if both head and tail are used, so we will translate matching pairs of get_hd and get_tl back to get_list instructions.
2018-01-26Merge pull request #1691 from bjorng/bjorn/compiler/local-cseBjörn Gustavsson
Do local common sub expression elimination (CSE)
2018-01-23beam_validator: Validate building of tuplesBjörn Gustavsson
Make sure that there is the correct number of put/1 instructions following put_tuple/2. Also make it illegal to reference the register for the tuple being built in a put/1 instruction. That is, beam_validator will now issue a diagnostice for the the following code: {put_tuple,1,{x,0}}. {put,{x,0}}.
2018-01-22Don't build a stacktrace if it's only passed to erlang:raise/3Bjö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.
2018-01-10Merge branch 'maint'Björn Gustavsson
* maint: beam_validator: Strengthen validation of GC instructions
2018-01-08beam_validator: Strengthen validation of GC instructionsBjörn Gustavsson
beam_validator did not verify that the Y registers were initialized before executing the following instructions that could cause a GC: bs_append/8 bs_init2/6 bs_init_bits/6 gc_bif1/5 gc_bif2/6 gc_bif3/7 test_heap/2 That means that, for example, an incorrect optimization that replaced an 'allocate_zero' instruction with an 'allocate' instruction when it was not safe, would not be rejected by beam_validtor, but would instead cause a crash or other undefined behavior at runtime. Also fix a minor bug in beam_type exposed by the stronger checking. When compiling from .S files, beam_type did not handle the init/1 instruction and could produce unsafe code.
2017-12-08Use the new syntax for retrieving stack tracesBjörn Gustavsson
2017-11-30Add syntax in try/catch to retrieve the stacktrace directlyBjö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-09-29Fix incorrect internal consistency failure for binary matching codeBjörn Gustavsson
4c31fd0b9665 made the merging of match contexts stricter; in fact, a little bit too strict. Two match contexts with different number of slots would be downgraded to the 'term' type. The correct way is to keep the match context but set the number of slots to the lowest number of slots of the two match contexts. https://bugs.erlang.org/browse/ERL-490
2017-08-30Make handling of match contexts stricterBjörn Gustavsson
beam_validator could fail issue a diagnostic when a register that was supposed to be a match context was not guaranteed to be a match context. The bug was in merging of types. Merging of a match context with another term would result in a match context. That is wrong. Merging should produce a more general type, not a narrower type. Also, the valid slots in two match contexts should be combined with 'band', not 'bor'.
2017-08-22Merge branch ↵Lukas Larsson
'john/compiler/fail-labels-in-blocks-otp-18/ERIERL-48/OTP-14522' into maint * john/compiler/fail-labels-in-blocks-otp-18/ERIERL-48/OTP-14522: compiler: Fix live regs update on allocate in validator Take fail labels into account when determining liveness in block ops Conflicts: lib/compiler/src/beam_utils.erl
2017-08-16compiler: Fix live regs update on allocate in validatorLukas Larsson
The state without pruned registers was passed on to test_heap causing the validator to belive registers that aren't live actually are live.
2017-05-04Update copyright yearRaimo Niskanen
2017-04-22Make beam_validator track type formation for binary operationsMichal Muskala
Fixes https://bugs.erlang.org/browse/ERL-406 - a bug introduced in 0377592dc2238f561291be854d2ce859dd9a5fb1
2017-03-24compiler: Add is_tagged_tuple instructionBjörn-Egil Dahlberg
Rewrite the instruction stream on tagged tuple tests. Tagged tuples means a tuple of any arity with an atom as its first element. Typically records, ok-tuples and error-tuples. from: ... {test,is_tuple,Fail,[Src]}. {test,test_arity,Fail,[Src,Sz]}. ... {get_tuple_element,Src,0,Dst}. ... {test,is_eq_exact,Fail,[Dst,Atom]}. ... to: ... {test,is_tagged_tuple,Fail,[Src,Sz,Atom]}. ...
2017-01-12Add specs for the beam_*:module/2 functionsBjörn Gustavsson
2016-11-02Support math:fmod/2 BIF on compilerGuilherme Andrade
2016-09-21beam_validator: Correct reporting of y register numberBjörn Gustavsson
The error would be: {multiple_match_contexts,[{x,0},2]} instead of: {multiple_match_contexts,[{x,0},{y,2}]}
2016-09-14Merge branch 'maint'Björn Gustavsson
* maint: beam_validator: Handle unreachable instructions Turn off parallel make for start scripts Makefile
2016-09-13beam_validator: Handle unreachable instructionsBjörn Gustavsson
ab03678e introduced an optimization in the beam_z pass that could introduce unreachable code in BEAM files (a 'jump' instruction is removed after a 'raise' instruction, but the code following the target of the 'jump' is not removed). Since this situation happens very rarely, there is no point in adding another pass that can remove unreachable code after beam_z. Instead we will make sure that beam_validator can skip the unreachable code. Skipping unreachable code is already done in valfun_1/2 (for historical reasons), but we will also need to do it in val_dsetel/2.
2016-09-05Add math:floor/1 and math:ceil/1Björn Gustavsson
Add math:floor/1 and math:ceil/1 to avoid unnecessary conversions in floating point expressions. That is, instead of having to write float(floor(X)) as part of a floating point expressions, we can write simply math:floor(X).
2016-09-05Implement the new ceil/1 and floor/1 guard BIFsBjörn Gustavsson
Implement as ceil/1 and floor/1 as new guard BIFs (essentially part of Erlang language). They are guard BIFs because trunc/1 is a guard BIF. It would be strange to have trunc/1 as a part of the language, but not ceil/1 and floor/1.
2016-06-02Eliminate crash for map updates in guardsBjörn Gustavsson
beam_validator would complain that x(1) is uninitialized in a test_heap instruction when attempting to compile the following code with sys_core_fold turned off: foo(M) when not (M#{true := 0}); [M] -> ok. Simplified, the generated BEAM assembly code looked like this: test is_map BadMap x(0) put_map_exact Fail x(0) => x(1) ... jump BooleanStuff BadMap: move ok => x(1) jump Fail BooleanStuff: ... move Boolean => x(2) jump Build Fail: move false => x(2) Build: test_heap 2 3 %% x(0), x(1), x(2) must be live. ... That is, if put_map_exact failed, control would transfer to the label Fail without initializing x(1). Fix that by making sure that x(1) is initilized even if put_map_exact fails: test is_map BadMap x(0) put_map_exact BadLbl x(0) => x(1) ... jump OkLbl BadLbl: move ok => x(1) jump Fail OkLbl: jump BooleanStuff BadMap: move ok => x(1) jump Fail BooleanStuff: ... move Boolean => x(2) jump Build Fail: move false => x(2) Build: test_heap 2 3 %% x(0), x(1), x(2) must be live. ... Note that this situation is rare, and that other optimization passes (beam_dead and beam_jump in particular) will clean up this mess.
2016-05-31beam_validator: Strengthen validation of match statesBjörn Gustavsson
We want to find bugs in the compiler during compilation. Validation of match contexts was weak, which could allow serious bugs in the generated code to slip through.
2016-05-31beam_validator: Use a record representing the match contextBjörn Gustavsson
Using a record will make it much easier to add additional information.
2016-05-30beam_validator: Add is_bitstring/1 as a safe BIFBjörn Gustavsson
beam_validator wrongly complained that the following was not safe because it didn't know that is_bitstring/1 is safe: food(Curriculum) -> [try is_bitstring(functions) catch _ -> 0 end, Curriculum]. While we are it, also add a new bif_SUITE test suite to cover some more code in beam_validator.
2016-05-30beam_validator: Remove uncovered lineBjörn Gustavsson
The raise/3 instruction is specially handled, thus there is no need for bif_type/3 to handle raise/3 (also, the number of arguments was incorrect, so it could never have matched).
2016-05-20beam_validator: Handle cons literals betterBjörn Gustavsson
As a preparation for better optimizations in beam_type, a list literal must be accepted as a 'cons'.
2016-05-20beam_validator: Keep better track of tuple literalsBjörn Gustavsson
As a preparation for upcoming better optimizations in beam_type, we will need to keep better track of tuple literals so that beam_validator will not falsely reject safe code.
2016-04-13Merge branch 'henrik/update-copyrightyear'Henrik Nord
* henrik/update-copyrightyear: update copyright-year
2016-04-08Remove unreachable code after 'raise' instructionsBjörn Gustavsson
Remove the unreachable instructions after a 'raise' instruction (e.g. a 'jump' or 'deallocate', 'return') to decrease code size.
2016-03-15update copyright-yearHenrik Nord
2015-11-16beam_validator: Don't allow an 'undefined' entry label in a functionBjörn Gustavsson
Before 912fea0b beam_validator could validate disassembled files. That's probably why the entry label was allowed to be 'undefined'.
2015-11-16beam_validator: Remove obsolete DEBUG supportBjörn Gustavsson
No one has used the debug support in many years. Also, the debug support is not free. There are calls to lists:foreach/2 that will be executed even when debug support is turned off.
2015-09-07Merge branch 'maint'Björn-Egil Dahlberg
2015-09-04compiler: Add extra checks for get_map_elements in validatorBjörn-Egil Dahlberg
2015-08-21beam_validator: Don't allow x(1023) to be usedBjörn Gustavsson
In 45f469ca0890, the BEAM loader started to use x(1023) as scratch register for some instructions. Therefore we should not allow x(1023) to be used in code emitted by the compiler.