Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[erlc] internal error in ssa_opt_type_continue #7478

Open
RobinMorisset opened this issue Jul 5, 2023 · 1 comment
Open

[erlc] internal error in ssa_opt_type_continue #7478

RobinMorisset opened this issue Jul 5, 2023 · 1 comment
Assignees
@bjorng
Labels
bug Issue is reported as a bug stalled waiting for input by the Erlang/OTP team team:VM Assigned to OTP team VM

Comments

@RobinMorisset
Copy link
Contributor

Describe the bug
Running erlc on the following testcase:

f(_V0) ->
    [ 0 ||
        begin bit_size(maybe 
            [] ?= maybe 
                0 ?= _V0,
                << 0 || _ <- []>>,
                ok
            end,
            _V0
        else
            _V0 -> _V0;
            ok -> _V0
        end),
        _V0 end,
    _ <- ok].

results in the following error message:

Sub pass ssa_opt_type_continue
Function: '-f/1-lc$^1/1-1-'/1
/home/rmorisset/minimized/test70696.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 446)
  in call from beam_ssa_type:opt_continue/4 (beam_ssa_type.erl, line 429)
  in call from beam_ssa_opt:ssa_opt_type_continue/1 (beam_ssa_opt.erl, line 437)
  in call from compile:run_sub_passes_1/3 (compile.erl, line 411)
  in call from beam_ssa_opt:phase/4 (beam_ssa_opt.erl, line 117)
  in call from beam_ssa_opt:fixpoint/6 (beam_ssa_opt.erl, line 100)
  in call from beam_ssa_opt:run_phases/3 (beam_ssa_opt.erl, line 86)

Affected versions
@RobinMorisset RobinMorisset added the bug Issue is reported as a bug label Jul 5, 2023
@IngelaAndin IngelaAndin added the team:VM Assigned to OTP team VM label Jul 5, 2023
@jhogberg jhogberg added the stalled waiting for input by the Erlang/OTP team label Jul 11, 2023
@RobinMorisset
Copy link
Contributor Author

Two simpler test cases with the exact same symptom:

f(_V0) ->
    << 0 || erlang:yield() and ([0 || _ <- _V0] =< 9223372036854775807), <<>> <= ok >>.

and

f(_V1) ->
    <<
        0
     || try
            [ 0 || _ := _ <- ok]
        catch
            _ ->
                false
        end and _V1,
        _ <- ok
    >>.

@RobinMorisset RobinMorisset mentioned this issue Jul 24, 2023
Open
frej added a commit to frej/otp that referenced this issue Jul 26, 2023
@frej
compiler: Don't apply beam_ssa_type on unreachable functions
3a0159d 
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
frej added a commit to frej/otp that referenced this issue Jul 26, 2023
@frej
compiler: Don't apply beam_ssa_type to unreachable functions
01525e0 
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
@frej frej mentioned this issue Jul 26, 2023
Closed
frej added a commit to frej/otp that referenced this issue Jul 26, 2023
@frej
compiler: Don't apply beam_ssa_type to unreachable functions
b3ca23f 
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
@bjorng bjorng self-assigned this Jul 31, 2023
@bjorng bjorng mentioned this issue Feb 28, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bjorng bjorng

Labels
bug Issue is reported as a bug stalled waiting for input by the Erlang/OTP team team:VM Assigned to OTP team VM
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bjorng @IngelaAndin @RobinMorisset @jhogberg