Backtrace source info lost in new compiled package image?

[quinnj]

Working on a locally developed package where I have an error during my __init__ function:

julia> using Flate, Test, Flate.GoTypes
[ Info: Precompiling Flate [9093563c-7325-43a3-bc6a-59ea82c1fd16]
ERROR: InitError: UndefVarError: `min` not defined
Stacktrace:
 [1] init(h::Flate.HuffmanDecoder, lengths::Flate.GoTypes.Go.Slice{Int64})
   @ Flate ~/.julia/compiled/v1.10/Flate/dVx3G_ADVEb.dylib:-1
during initialization of module Flate

With the problem being @ Flate ~/.julia/compiled/v1.10/Flate/dVx3G_ADVEb.dylib:-1 where I don't have a file + line of where the error is happening. Can produce the local package setup if that's helpful.

[vchuravy]

Would be great to have a self-contained test case for this. I fixed something similar, but that was slightly different.

[timholy]

At least in principle there may be circumstances where precompiling __init__ is a bad idea; I'd worry our constprop could conceivably "bake in" some constants that actually aren't constant. Hopefully we don't do that, but...

Just to see if it fixes the issue, can you easily omit __init__ from the precompilation?

[vchuravy]

I don't think the issue here is precompilation of __init__ there is just a method called init, and we didn't attach the debug-information properly.

[quinnj]

Ok, the package is currently pretty self-contained, so I made a branch of the broken state: https://github.com/quinnj/Flate.jl/tree/jq/broken. If you dev that and do using Flate, you should see the broken backtrace.

[quinnj]

(It is __init__ related, it's just a bit confusing because it does call an init function from __init__)

[gbaraldi]

Yesh, it is init related.

This is enough to reproduce it

module MyPkg

function __init__()
    error("is this loss?")
end

end # module MyPkg

and load this as a package.

julia> using MyPkg
ERROR: InitError: is this loss?
during initialization of module MyPkg

[vtjnash]

Duplicate of #47744 ?

[gbaraldi]

We get the traces for everything else except init, so I'm not sure it's the same

[vchuravy]

On Linux I get:

julia> using MyPkg
[ Info: Precompiling MyPkg [8692d6f5-ce38-47f5-ad06-b8a7980b6200]
ERROR: InitError: Is this loss?
Stacktrace:
  [1] error
    @ ./error.jl:35
  [2] __init__()
    @ MyPkg ~/MyPkg/src/MyPkg.jl:3
  [3] register_restored_modules(sv::Core.SimpleVector, pkg::Base.PkgId, path::String)
    @ Base ./loading.jl:1014
  [4] _include_from_serialized(pkg::Base.PkgId, path::String, ocachepath::String, depmods::Vector{Any})
    @ Base ./loading.jl:958
  [5] _tryrequire_from_serialized(pkg::Base.PkgId, path::String, ocachepath::String)
    @ Base ./loading.jl:1297
  [6] _require(pkg::Base.PkgId, env::String)
    @ Base ./loading.jl:1671
  [7] _require_prelocked(uuidkey::Base.PkgId, env::String)
    @ Base ./loading.jl:1515
  [8] macro expansion
    @ ./loading.jl:1503 [inlined]
  [9] macro expansion
    @ ./lock.jl:267 [inlined]
 [10] require(into::Module, mod::Symbol)
    @ Base ./loading.jl:1466
during initialization of module MyPkg

[gbaraldi]

Do we store that debuginfo as dwarf in the dylib?

[vchuravy]

No I don't think we are using dwarf for this. We use the JITDebugInfoRegistry (see add_image_info) to register the function pointers with Julia so that it can symbolize these correctly.

[vchuravy]

I don't have a Mac machine available while I am traveling so I would be grateful if someone else could dig in. I would use LLDB to step through the backtrace collection