Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backtrace source info lost in new compiled package image? #48020

Closed
quinnj opened this issue Dec 28, 2022 · 19 comments · Fixed by #48544
Closed

Backtrace source info lost in new compiled package image? #48020

quinnj opened this issue Dec 28, 2022 · 19 comments · Fixed by #48544
Labels
pkgimage system:mac Affects only macOS
Milestone

Comments

@quinnj
Copy link
Member

quinnj commented Dec 28, 2022

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
Copy link
Member

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

@timholy
Copy link
Member

timholy commented Dec 28, 2022

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
Copy link
Member

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.

@vchuravy vchuravy added this to the 1.9 milestone Dec 28, 2022
@vchuravy vchuravy added pkgimage system:mac Affects only macOS labels Dec 28, 2022
@quinnj
Copy link
Member Author

quinnj commented Dec 28, 2022

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
Copy link
Member Author

quinnj commented Dec 28, 2022

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

@gbaraldi
Copy link
Member

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
Copy link
Member

vtjnash commented Dec 28, 2022

Duplicate of #47744 ?

@gbaraldi
Copy link
Member

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

@vchuravy
Copy link
Member

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
Copy link
Member

Do we store that debuginfo as dwarf in the dylib?

@vchuravy
Copy link
Member

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
Copy link
Member

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

@gbaraldi
Copy link
Member

libunwind isn't finding any traces, while lldb finds them just fine. It might be an LLVM Libunwind bug.

@giordano
Copy link
Contributor

I get the same with LLVM libunwind 14.0.6, if it's a bug in that library it hasn't been fixed until that version (I haven't tried with v15).

@gbaraldi
Copy link
Member

gbaraldi commented Jan 5, 2023

Me and @vchuravy debugged this, It's not due to libunwind, but instead lld-14 doing something wrong, while experimenting we found that lld15 and l64 both get the correct results here. Since getting llvm15 for 1.9 is a no go I will try to find the commits that fixed this and backport them.

@gbaraldi
Copy link
Member

gbaraldi commented Feb 8, 2023

I don't think we can close this, it seems to be still broken on macos 12

@KristofferC KristofferC reopened this Feb 8, 2023
@gbaraldi
Copy link
Member

gbaraldi commented Feb 8, 2023

Using lld-15 on macos 12.3 does fix it. 🤔
On our CI machines the fix does work(12.3), so I'm a bit stumped.

@giordano
Copy link
Contributor

giordano commented Feb 8, 2023

I don't think we can close this, it seems to be still broken on macos 12

For the record, we clarified offline the only thing that had been fixed by #48544 is #48020 (comment) (which at this point should have been a separate issue). The original issue reported here with file:line info being lost for errors thrown inside __init__ has never been fixed for anyone.

@gbaraldi
Copy link
Member

gbaraldi commented Feb 8, 2023

The solution for this is generating .dSYM files for the package images. Which requires us to ship dsymutil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkgimage system:mac Affects only macOS
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants