`juliac` segfault during `const` statement

[RomeoV]

Summary

juliac segfaults when a somewhat involved const = ... statement is evaluated that's not in a package definition.

Description

While working on a --trim CI test for NonlinearSolve.jl (SciML/NonlinearSolve.jl#665) I came across the following segfault:
I have some code that's roughly

const autodiff = AutoForwardDiff(; chunksize = 1)
const alg = TrustRegion(; autodiff, linsolve = LS.CholeskyFactorization())
const prob = NonlinearLeastSquaresProblem{false}(...)
const cache = init(prob, alg)

function minimize(x)
    reinit!(cache, x)
    solve!(cache)
    return cache.u
end

with a relatively straightforward objective function (just a linsolve and cholesky on a regular Vector).

When using an appropriate entrypoint that calls minimize this program trims fine, as long as the code is in a package definition. However, when it is merely wrapped in a module, or simply included, the cache = init(prob, alg) segfaults the juliac compiler.

In particular, trying to trim

include("optimization_trimmable.jl")
function (@main)(argv::Vector{String})::Cint
    minimize(1.0)
    return 0
end

or even

module MyMod
    include("optimization_trimmable.jl")
end
function (@main)(argv::Vector{String})::Cint
    MyMod.minimize(1.0)
    return 0
end

segfaults juliac.

What I expected to happen

That is trims just fine, as it does when we swap out main_segfault.jl with main_trimmable.jl below.

How to reproduce

git clone git@github.com:RomeoV/NonlinearSolve.jl.git
cd NonlinearSolve.jl
git checkout ca0d0f2a8cf752a68c48ab88cf4c850bb1acbc49
cd test/trim
export JULIAC=$(julia +1.12 -E 'joinpath(Sys.BINDIR, Base.DATAROOTDIR, "julia", "juliac", "juliac.jl")' | tr -d '"')
julia +1.12 --depwarn=error --project ${JULIAC} --experimental --trim=unsafe-warn --output-exe main main_segfault.jl

[JeffBezanson]

This is probably due to initializers not being run. Juliac uses sysimage-style output where __init__ doesn 't get called. This is very hard to catch because we don't know what to check to see whether something required init to be run. For now the cache should be initialized using OncePerProcess.

[RomeoV]

I'm trying to use OncePerProcess{T} now. Does the type need to be hard-coded into the code, or can it be inferred for juliac? The typeof(cache) is very long and complicated, I think it would be a struggle to hard-code it.

However, without explicitly writing the type I'm running into issues with --trim where the compile seemingly gives up, stops mid-output and concludes "Failed to compile main_segfault.jl".

[topolarity]

However, without explicitly writing the type I'm running into issues with --trim where the compile seemingly gives up, stops mid-output and concludes "Failed to compile main_segfault.jl".

With no other output? That is worth an issue of its own, please!

[JeffBezanson]

I'm trying to use OncePerProcess{T} now. Does the type need to be hard-coded into the code, or can it be inferred for juliac? The typeof(cache) is very long and complicated, I think it would be a struggle to hard-code it.

Yes we should be able to infer it with just OncePerProcess() do ... end if the code is otherwise inferrable.

[RomeoV]

With no other output? That is worth an issue of its own, please!

Ok I checked it again and actually there is output.
What's happening is:

Verifier error #11: <...>
[first half of verifier output with very(!) long SciMLType]
[fatal: error thrown and no exception handler available.
MethodError(f=Base.Enums.namemap, args=(SciMLBase.ReturnCode.T,), world=0x0000000000009661)]
[... c callstack ...]
[second half of verifier output, which is just the rest of the SciMLType]

So I guess there's just some race condition when printing, but the output can be seen by scrolling up a bit.