aboutsummaryrefslogtreecommitdiffstats
path: root/erts/lib_src/pthread/ethread.c
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2019-08-01 18:42:09 +0200
committerBjörn Gustavsson <[email protected]>2019-08-05 13:00:46 +0200
commite6c818956cadeb90f62f61ee5263ba4035be40c4 (patch)
treec6922ece2ea18fac10bd767b10384f204214a1b5 /erts/lib_src/pthread/ethread.c
parent3967d28c05dae77db30b15e56eb4ececf4f1afef (diff)
downloadotp-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/lib_src/pthread/ethread.c')
0 files changed, 0 insertions, 0 deletions