Thanks for your report! This is definitely a bug. One thing you can do is add a try/catch in beam_ssa_recv:module/2 that dumps the #b_module{} record, that'll give us the offending file as seen by the pass.

Status update. The crash is when it checks pu_is_ref_used at the Mon in {'DOWN', Mon, process, Pid, Reason0} -> on the line "5" in this snippet:

shutdown(#child{pid=Pid, shutdown=Time} = Child) ->
    Mon = monitor(process, Pid),
    exit(Pid, shutdown),
    receive
        {'DOWN', Mon, process, Pid, Reason0} ->                      %%% <--- here
            case unlink_flush(Pid, Reason0) of
                shutdown ->
                    ok;
                {shutdown, _} when not (?is_permanent(Child)) ->
                    ok;
                normal when not (?is_permanent(Child)) ->
                    ok;
                Reason ->
                    {error, Reason}
            end
    after Time ->
        exit(Pid, kill),
        receive
            {'DOWN', Mon, process, Pid, Reason0} ->
                case unlink_flush(Pid, Reason0) of
                    shutdown ->
                        ok;
                    {shutdown, _} when not (?is_permanent(Child)) ->
                        ok;
                    normal when not (?is_permanent(Child)) ->
                        ok;
                    Reason ->
                        {error, Reason}
                end
        end
    end.

This code is verbatim copied from https://github.com/erlang/otp/blob/master/lib/stdlib/src/supervisor.erl#L1495-L1525 . The probability of nobody finding this before me in such a core module seems incredibly low, so I bet something else is up.

Repro steps

Reproduction steps, on my machine only, where asdf and qwer are placeholder names:

/opt/homebrew/Cellar/erlang/26.2.5/lib/erlang/lib/compiler-8.4.3/ebin$ /opt/homebrew/Cellar/erlang/26.2.1/lib/erlang/bin/erlc ../src/beam_ssa_recv.erl; erlc ../src/beam_ssa_recv.erl

~/asdf/code/qwer$ PURERLEX_VERBOSE=1 iex --dbg pry -S mix phx.server

rm -r /Users/drathier/asdf/code/qwer/_build/dev/lib/asdf

`recompile` in iex

hopefully trigger bug, otherwise redo all previous steps

Small repro

Here's a smaller version that's enough to trigger the bug:

-module(supervisor2).

asdf(Pid) ->
    Mon = monitor(process, Pid),
    receive
        {'DOWN', Mon, process, Pid, _} ->
            ok
    end.

• {'DOWN', Mon, process, Pid, _} -> does not compile, reproduces the above error
• {'DOWN', Mon2, process, Pid, _} -> compiles ok
• {'DOWN', Mon, process, Pid2, _} -> compiles ok
• {'DOWN', Mon2, process, Pid2, _} -> compiles ok

Questions and Next steps

• Q1: Is this compiler pass skipping some modules by name, to avoid known issues in very rarely written code? I can reproduce this bug with this exact version https://raw.githubusercontent.com/erlang/otp/OTP-26.2.5.3/lib/stdlib/src/supervisor.erl and just the -module(supervisor2). line changed. This is the only explanation I can think of right now as for why I would be the first one triggering this bug.
• Q2: Is this worth investigating further? Is there anything you'd like me to dig into further? I don't know what the next steps debugging this would be.

Thanks, that is very odd. Am I right in assuming that this runs on an ARM Mac? Can you reproduce this if you build OTP without the JIT? (./otp_build --disable-jit)

Also, if you could post the raw #b_module{} somewhere that'd be great too. I've been unable to reproduce this on the machines we have, and would like to know whether the #b_module{} looks like it should at this point, whether there's an issue with true = beam_ssa:no_side_effect(I),, beam_ssa:no_side_effect/1 being broken, etc.

• I'm using an m2 arm mac, yes.
• I just realised the ERL_COMPILER_OPTIONS="[no_bool_opt]" was set in an .env file, and that it's seemingly required to trigger the small repro version of this bug.

supervisor2.erl had the contents of the small repro posted above, and I got these outputs:
https://gist.github.com/drathier/cc2770e83416d3e435683264b574c7ca
EDIT: I modified the code to grab the stack traces too, but didn't re-run the tests after adding them. Lmk if you want the stack traces too :)

I hope this is enough for you to reproduce this bug, or to dismiss it as wontfix. I don't know if you officially support disabling compilation steps. I know I've hit compiler bug(s) before from skipping compiler optimization passes, possibly this same one, don't remember. Thanks for rubber ducking this with me, I'm now unblocked again :)

• This feels like enough of a finding to possibly reproduce it on your machine, so I'll wait and see how it does before I dig any further.
• I haven't tested the large file
• I haven't tried without jit
• I had disabled some compiler passes to speed up compilation sometime earlier (actually ERL_COMPILER_OPTIONS="[no_bool_opt,no_stack_trimming]") and left it in an .env file and forgotten about it :/

Thanks! I can reproduce it just fine now, it's a benign bug in code generation: it crashes on a succeeded:body check that should've been generated as a succeeded:guard. It should have no ill effects other than suppressing some optimizations or crashing on assertions like this.