Julia 1.10: segfault in `jl_rettype_inferred`

[kpamnany]

Opened for tracking. This crash happened intermittently on RAI's 1.10.2 (+various backports) build, after we loaded some package images containing only method specializations.

We have previously shared an rr trace and are working with @gbaraldi to find the problem.

[61] signal (11.1): Segmentation fault
in expression starting at none:1
signal (11) thread (3) jl_rettype_inferred at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/gf.c:447
signal (11) thread (3) emit_invoke at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:4421
signal (11) thread (3) emit_invoke at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:4394 [inlined]
signal (11) thread (3) emit_expr at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:5493
signal (11) thread (3) emit_ssaval_assign at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:5101
signal (11) thread (3) emit_stmtpos at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:5335 [inlined]
signal (11) thread (3) emit_function at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:8380
signal (11) thread (3) jl_emit_code at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:8715
signal (11) thread (3) jl_emit_codeinst at /build/julia-v1.10.2+RAI-ce667bce9441b77c780f9b74e394784dc4cb3631/src/codegen.cpp:8789
<snip>

[gbaraldi]

Small context:
This is an applications that uses packages that define no methods but only have specializations in the images to save code.
The bug manifested as corrupted IR which caused a segfault after a OOB dereference.
After way too much debugging with @kpamnany. We realized this was an issue with the deserialization of compressed IR. Specifically one of the objects in the method roots was wrong.
After staring at it a bunch, we realized that this is a clobber of the root_blocks structure. It uses a kind of hash table that uses the low bits of the build_id as a key.
However it seems this code is not reliable under a build_id collision of the low bits. Which is what happened in the modules of those packages.

I imagine that this hasn't been seen before because for this to be observed you need a collection of improbable things.

1. Collision of the hashes
2. Both modules have to extend that same method
3. The compressed IR has to be used (it might only be used when inlining that method)
4. None of it gets invalidated

Not sure what solution for this is, but I imagine it's not too too difficult.

@topolarity @vtjnash

TLDR:

Module1.build_id.lo == Module2.build_id.lo
and
Module1 and Module 2 extend the same method
so
collision causes corruption of the rootblocks which causes errors downstream if this is ever observed

See how there is a repeated entry into the root_blocks which will cause all matter of fun issues.

julia> metis.def.root_blocks
8-element Vector{UInt64}:
 0x0061aca4a8b1aac9
 0x0000000000000000
 0x0000000000000000
 0x0000000000000006
 0x000000269b948bae
 0x00000000000000fa
 0x000000269b948bae
 0x0000000000000107