diff options
author | Björn Gustavsson <[email protected]> | 2019-08-01 18:42:09 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2019-08-05 13:00:46 +0200 |
commit | e6c818956cadeb90f62f61ee5263ba4035be40c4 (patch) | |
tree | c6922ece2ea18fac10bd767b10384f204214a1b5 /erts/start_scripts/Makefile | |
parent | 3967d28c05dae77db30b15e56eb4ececf4f1afef (diff) | |
download | otp-e6c818956cadeb90f62f61ee5263ba4035be40c4.tar.gz otp-e6c818956cadeb90f62f61ee5263ba4035be40c4.tar.bz2 otp-e6c818956cadeb90f62f61ee5263ba4035be40c4.zip |
Ensure that the stack slots are initialized when matching maps
When matching a map, the compiler could fail to generate code that
would initialize all stack slots (Y registers) properly. Here is a
general outline of code that *could* cause this problem:
foo(Key, Map) ->
Res = case Map of
#{Key := Val} ->
%% Do something with Val here.
.
.
.
#{} ->
[]
end,
%% The stack slot for Val might not have been initialized
%% here if the key was not present in the map.
.
.
.
%% Use Res.
.
.
.
The code generator would wrongly assume that the map matching would
always initialize the stack slot, and if nothing else happened to
force that stack slot to be initialized, it would remain
uninitialized, which would likely crash the runtime system at the next
garbage collection.
`beam_validator` is supposed to find these kind of problems, but a bug
in `beam_validator` prevented it from detecting this problem.
https://bugs.erlang.org/browse/ERL-1017
Diffstat (limited to 'erts/start_scripts/Makefile')
0 files changed, 0 insertions, 0 deletions