Internal compiler error in ssa_opt_type_continue #7509
Comments
|
Thanks for the mention! |
Looks very likely, I wonder what I did wrong when I searched for Permuting the order of functions returned by |
|
Crashing on In the absence of bugs like these, the result will be equivalent regardless of work order, so I prefer to leave it undefined to help shake more bugs out. I’ll look deeper into it today. :) |
The beam_ssa_type:opt_continue/4 pass requires that type information is available for all arguments or else it will crash with a back trace similar to this: Sub pass ssa_opt_type_continue Function: '-f3/1-lc$^0/1-3-'/1 test362604.erl: internal error in pass beam_ssa_opt: exception error: no function clause matching beam_types:join([]) in function beam_ssa_type:join_arg_types/3 (beam_ssa_type.erl, line 449) in call from beam_ssa_type:opt_continue/4 (beam_ssa_type.erl, line 432) in call from beam_ssa_opt:ssa_opt_type_continue/1 (beam_ssa_opt.erl, line 449) in call from compile:run_sub_passes_1/3 (compile.erl, line 424) in call from beam_ssa_opt:phase/4 (beam_ssa_opt.erl, line 116) in call from beam_ssa_opt:fixpoint/6 (beam_ssa_opt.erl, line 99) in call from beam_ssa_opt:run_phases/3 (beam_ssa_opt.erl, line 85) If type analysis during beam_ssa_type:opt_start/2 concludes that a function is never called, type information for the callee will never be recorded, thus leaving no type information for the arguments in the function's entry in the function database, leading to the crash above. Although naively unreachable functions are pruned when the list of functions is first traversed in beam_ssa_type:opt_start/2, it doesn't handle they case when type inference concludes that a function is never called. This patch extends beam_ssa_type:opt_start/2 to, when all functions have been processed, prune non-exported functions for which #func_info.arg_types is just a list of empty dictionaries. That a function of zero arity is always considered reachable, is harmless as it won't crash opt_continue/4. Closes erlang#7509 Closes erlang#7478
The beam_ssa_type:opt_continue/4 pass requires that type information is available for all arguments or else it will crash with a back trace similar to this: Sub pass ssa_opt_type_continue Function: '-f3/1-lc$^0/1-3-'/1 test362604.erl: internal error in pass beam_ssa_opt: exception error: no function clause matching beam_types:join([]) in function beam_ssa_type:join_arg_types/3 (beam_ssa_type.erl, line 449) in call from beam_ssa_type:opt_continue/4 (beam_ssa_type.erl, line 432) in call from beam_ssa_opt:ssa_opt_type_continue/1 (beam_ssa_opt.erl, line 449) in call from compile:run_sub_passes_1/3 (compile.erl, line 424) in call from beam_ssa_opt:phase/4 (beam_ssa_opt.erl, line 116) in call from beam_ssa_opt:fixpoint/6 (beam_ssa_opt.erl, line 99) in call from beam_ssa_opt:run_phases/3 (beam_ssa_opt.erl, line 85) If type analysis during beam_ssa_type:opt_start/2 concludes that a function is never called, type information for the callee will never be recorded, thus leaving no type information for the arguments in the function's entry in the function database, leading to the crash above. Although naively unreachable functions are pruned when the list of functions is first traversed in beam_ssa_type:opt_start/2, it doesn't handle they case when type inference concludes that a function is never called. This patch extends beam_ssa_type:opt_start/2 to, when all functions have been processed, prune non-exported functions for which #func_info.arg_types is just a list of empty dictionaries. That a function of zero arity is always considered reachable, is harmless as it won't crash opt_continue/4. Closes erlang#7509 Closes erlang#7478
The beam_ssa_type:opt_continue/4 pass requires that type information is available for all arguments or else it will crash with a back trace similar to this: Sub pass ssa_opt_type_continue Function: '-f3/1-lc$^0/1-3-'/1 test362604.erl: internal error in pass beam_ssa_opt: exception error: no function clause matching beam_types:join([]) in function beam_ssa_type:join_arg_types/3 (beam_ssa_type.erl, line 449) in call from beam_ssa_type:opt_continue/4 (beam_ssa_type.erl, line 432) in call from beam_ssa_opt:ssa_opt_type_continue/1 (beam_ssa_opt.erl, line 449) in call from compile:run_sub_passes_1/3 (compile.erl, line 424) in call from beam_ssa_opt:phase/4 (beam_ssa_opt.erl, line 116) in call from beam_ssa_opt:fixpoint/6 (beam_ssa_opt.erl, line 99) in call from beam_ssa_opt:run_phases/3 (beam_ssa_opt.erl, line 85) If type analysis during beam_ssa_type:opt_start/2 concludes that a function is never called, type information for the callee will never be recorded, thus leaving no type information for the arguments in the function's entry in the function database, leading to the crash above. Although naively unreachable functions are pruned when the list of functions is first traversed in beam_ssa_type:opt_start/2, it doesn't handle they case when type inference concludes that a function is never called. This patch extends beam_ssa_type:opt_start/2 to, when all functions have been processed, prune non-exported functions for which #func_info.arg_types is just a list of empty dictionaries. That a function of zero arity is always considered reachable, is harmless as it won't crash opt_continue/4. Closes erlang#7509 Closes erlang#7478
|
Like I said before, this kind of crash happens when another bug suddenly makes previously unreachable code reachable. That bug is #7342/#6599 in this case (failure to propagate type information between tests on different variables relating in some way to the same value). #7512 fixes the crash by sweeping the bug under the rug, which I don't want to do in the general case because the code being unreachable at first could have been an error. It happens to be safe in this particular case, but we can't say that it will always be so. |
My take is the exact opposite. The crashes in the reproducers of #7478 and #7512 are because an unreachable function is, on entry to My analysis is that on entry to Unless we prune functions which become unreachable when we use type knowledge The only bug I can see being swept under the rug with #7512, is if something is wrong with the type analysis so that it considers reachable code unreachable. But in that case, what stops us from crashing when it is right and a function which looks reachable turns out not to be, during |
|
You're looking at the wrong part of the code, the initial problem occurs much earlier during This confuses the heck out of Pruning the functions once more as in #7512 hides the bug in |
|
I see, that makes sense. I'll withdraw #7512. |
Describe the bug
Erlc can sometimes crash with a back-trace like this:
To Reproduce
Unless the patch below is applied, the crash appears to be dependent on the phase of the moon :) With the patch applied, the reproducer (found with Erlfuzz, thanks @RobinMorisset ) triggers the error reliably.
Affected versions
At least
maint(fe0571e)Additional context
As far as I can tell,
beam_ssa_type:signatures_1/2can produce a different#sig_st{}andFuncDbdepending on the order of the initial worklist in the#sig_st{}. This, in turn, leads to number of list-comprehension functions being eliminated from optimization when the compilation succeeds, but kept around when the crash occurs.The text was updated successfully, but these errors were encountered: