diff options
author | Björn Gustavsson <[email protected]> | 2016-01-07 15:25:26 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2016-01-11 14:37:44 +0100 |
commit | f0bc967c38d8859ff794e93082e9d2fb495f34d3 (patch) | |
tree | 0d4426d71dfe543abb8f9e27bab6bbc04c24ab25 /otp_patch_apply | |
parent | c0ff4189f752fdfe20b231492b2084dfe8cecdb2 (diff) | |
download | otp-f0bc967c38d8859ff794e93082e9d2fb495f34d3.tar.gz otp-f0bc967c38d8859ff794e93082e9d2fb495f34d3.tar.bz2 otp-f0bc967c38d8859ff794e93082e9d2fb495f34d3.zip |
Eliminate crash in v3_codegen
The following code would crash v3_codegen:
order(From) ->
catch
if
From#{[] => sufficient} ->
saint
end.
Before explaining the crash, first some background on the stack
frame and the Y registers.
Certain instructions, most notably the 'call' instructions, clobber
all X registers. Before any such instruction, all X registers that
have values that will be used after the call must be saved to Y
registers (i.e. to the stack frame). adjust_stack/4 will be called
when X registers must be saved.
There is also another situation when X registers must be saved, namely
within a 'catch' if we are about to execute any instruction that may
cause an exception. Examples of such instructions are some guard BIFs
(such as length/1) and construction of binaries or maps. Within a
'catch', X registers must be be saved because if an exception is
thrown and catched all X registers will be destroyed. The same
adjust_stack/4 function will be called for those instructions, but
only if they occur within a 'catch'.
There is actually one more complication. If there is code in
a guard within a catch, the X registers should not be saved, because
the code in a guard never clobbers any X registers that were alive
before the guard code was entered. v3_codegen is written with the
implicit assumption that code in guards never cause anything
to be saved to Y registers.
The code for building maps and binaries would incorrectly save X
registers within a guard inside a 'catch'.
For construction of binaries, that would mean that a useless but
harmelss 'move' instruction was generated.
But for construction of maps, the saving of the Y register would not
be harmless. There would be a crash when attempting to merge #sr{}
records. #sr{} records keeps track of the contents of X and Y
registers. When two separate code paths are joined (e.g. at the end of
'case' statement), the register descriptors must be reconciled.
Basically, the register descriptors for both paths must be identical.
The #sr{} record for one path must not claim that {y,0} contains
a certain value, while another path claims that {y,0} is dead.
Thus, the crash occurs in sr_merge/2 when failing to reconcile the
Y registers.
To fix this bug this bug we will introduce a new function called
maybe_adjust_stack/5. It will save X registers on the stack only
if the code is inside a catch but not inside a guard. We will
change all existing code to use this new function when appropriate.
Reported-by: Thomas Arts
Diffstat (limited to 'otp_patch_apply')
0 files changed, 0 insertions, 0 deletions