After #22210, tests of ACME.jl end in a crash (ref. #22210 (comment)), reproducible with

Pkg.add("ACME", v"0.4.1", v"0.4.1+")
Pkg.test("ACME")

As Pkg.test("ACME") takes quite long, the much quicker repro is

using ACME
for i in 1:10000
    @show i
    mats = ACME.model_matrices(Circuit(), 1)
end

The iteration in which the crash occurs and the exact error and backtrace vary, but a value whose type is not a type at all seems to be a recurring theme. However, adding a gc() to model_matrices(...) with

diff --git a/src/ACME.jl b/src/ACME.jl
index 466a26d..ab7fd74 100644
--- a/src/ACME.jl
+++ b/src/ACME.jl
@@ -509,6 +509,7 @@ function model_matrices(circ::Circuit, t::Rational{BigInt})
         res[v] = squeeze(res[v], 2)
     end
 
+    gc()
     p = [pv(circ) pi(circ) px(circ)//2+pxd(circ)//t pq(circ)]
     if normsquared(p * indeterminates) > 1e-20
         warn("Model output depends on indeterminate quantity")

consistently leads to a crash in iteration 1. The crash here actually occurs when trying to show a MethodError, this is an excerpt from a GDB session:

#12 0x00007ffff757b6af in jl_apply_generic (args=0x7fffffffa620, nargs=2) at ./src/gf.c:1928
1928	    jl_value_t *res = jl_call_method_internal(mfunc, args, nargs);
(gdb) call jl_(args[0])
getfield(Base, Symbol("##494#495")){Base.MethodError}(ex=Base.MethodError(f=typeof(Base.:(*))(), args=<?#0x7fffe8f76990::Array{UInt64, 1}[0xffffffffffffffff]>, world=0x0000000000005675))

Note the garbled inner args, where the type is an array instance (and trying do to something with that then hits an assertion further down the backtrace), hence my guess that this is a use-after-free.

My very wild guess is that the new inlining heuristics due to #22210 lead to code that somehow confuses the GC. But I'm way over my head here. If there is anything I can do to obtain/provide more information, I'm all ears.