Segfault when revising package #675
Comments
|
OK I can also reproduce it on x86_64 Linux: |
|
I could try to reduce the example (i.e. hack down Oscar.jl to a minimal version that still repros the issue), but that'll be quite some work, so I am not sure when I'd find the time. In the meantime, perhaps someone has an idea already with this (at least now anyone has a chance to repro it, and e.g. attach a debugger) |
Can you get an rr trace? Just start Julia with |
|
@DilumAluthge OK. Hmm, seems this does not play nice with the |
|
|
I'm new to portable Maybe a path error? That archive has a file named This is probably a Julia bug rather than Revise bug so it might be best to report there. FYI I can't replicate the crash locally. |
|
CC @Keno who might have some insight |
|
I am right now trying to bisect Julia for this, too, after all it worked a few works ago (but it's sloooooow to rebuild Julia each time... sigh) |
|
Turning off the precompile stuff ( |
|
I periodically learn and then forget that trick, thanks for the reminder. |
|
bisected it to JuliaLang/julia@7b1e454 from JuliaLang/julia#43671 by @simeonschaub |
|
Is this only on 1.8, not 1.9? Trying this on the latest Julia master, I only get the following errors: |
|
I still get this on the |
|
@Keno Is there a way to take an rr trace that was generated without debug symbols, and load the debug symbols in separately? |
|
The issue definitely occurs in master, too. Try to I can try to make another rr snapshot with debug symbols active tonight. |
|
I think the |
|
I've now used the following script on an Ubuntu machine to temporarily hack the JLL libraries for use with a debug build of Julia: #!/bin/sh
#
# using GAP_jll, GAP_pkg_juliainterface_jll, libcxxwrap_julia_jll, libpolymake_julia_jll, libsingular_julia_jll
# for m in [GAP_jll, GAP_pkg_juliainterface_jll, libcxxwrap_julia_jll, libpolymake_julia_jll, libsingular_julia_jll] println(m.find_artifact_dir()) end
#
for f in \
c839838c859a6318d38122f94bfadd353cddf129/lib/libgap.so \
9a3ef36e44865786948fe5b9f4cf0fbc7d737718/lib/gap/JuliaInterface.so \
4266ab44a39180f4d3be858e3fe507874d13fca1/lib/libcxxwrap_julia.so \
18e245078af62a7a8a839d00850ccd849c7af16b/lib/libpolymake_julia.so \
a625ffb5bfe38061a69a6fdf210f9988564b09b7/lib/libsingular_julia.so \
; do
chmod a+w $HOME/.julia/artifacts/$f
patchelf --replace-needed libjulia.so.1 libjulia-debug.so.1 $HOME/.julia/artifacts/$f
#patchelf --replace-needed libjulia-debug.so.1 libjulia.so.1 $HOME/.julia/artifacts/$f
doneI also noticed that perhaps not every "edit a file of Oscar.jl" triggers the crash, so here is what I am now doing specifically to reliably trigger the crash: touch(abspath(pathof(Oscar),"..","Groups","GAPGroups.jl"));I'll now try to get that rr trace |
|
That's great work, thanks! I think this should help a lot. I tried to rename the soname of |
|
It's still rather obscure but I have one potential suspicion. This seems to have something to do with symbol lookup, so I'm wondering whether this might be an issue with some jll having been linked to a Do you know what exact version of Julia the jlls are linked against? JuliaLang/julia@7b1e454 touched a couple of parts in libjulia, so I could imagine that those caused the artifacts linking to it to be out of sync. |
See https://github.com/JuliaPackaging/Yggdrasil/blob/db23b4c8d4bec230c46532dc1f67542f9930ff70/L/libjulia/common.jl#L47. Commit JuliaLang/julia@7a1c20e is after JuliaLang/julia@7b1e454 |
|
Could it potentially be an issue that libjulia_jll's dependents are built against an older version? I am not sure |
|
JuliaPackaging/Yggdrasil#4520 was a week after JuliaPackaging/Yggdrasil#4461. However it may still be a good idea to rebuild libjulia on 1.8.0-beta-1, to have a more stable reference |
|
That's not the only one building against Specifically |
|
They were all rebuilt for 1.9, after it branched, which was after your PR. In fact, they had to be rebuilt, as those JLLs carry different binaries for each Julia minor version, which indeed tend to be binary incompatible. |
|
That said, my bisecting of course could have been affected leading to me flagging the wrong commit. But that seems unlikely due to the nature of the crash. But not impossible... |
|
FWIW, I'm also seeing a segfault when using Revise with Julia 1.8 on an M1 mac. Some additional data points:
This is a private package using DataFrames 1.3.2 and XLX 0.7.9 Julia 1.8.0-beta2.3 using Baz
bar("file_name.xlsx")
# executes without problem
# Revise the module Baz: comment out an unrelated function
bar("file_name.xlsx")
signal (11): Segmentation fault: 11Full segfault output:In Julia 1.9.0-DEV.211, instead of the segfault in response to editing the module, the following exception occurs: And in Julia 1.8.0-DEV.1483, Revise works without any errors after editing the module.
versioninfo 1.8.0-DEV.1483versioninfo 1.8.0-beta2.3versioninfo 1.9.0-DEV.211 |
|
Could we move this issue to Julia base? |
|
You can't really transfer the issue using the github feature, that's only within the same organisation. You'll have to open a new one |
|
Ah, that's unfortunate! |
|
The segfault in |
|
If it's known older versions of the package aren't compatible with julia v1.8, that should be reflected in the registry. I know some people don't like changing compat bounds retroactively, but the alternative is to get broken packages |
|
Updated JuliaInterpreter to 0.9.11: the segfault disappeared in Julia 1.8.0-beta2.3 as did the exception being thrown by 1.9.0-DEV.211. Wish all issues were that easy to fix! Grateful for @Keno's diagnosis. I have added JuliaInterpreter to my version's base environments rather than rely on dependency compats. That will remind me to update it at the same time as Revise. |
Submit a PR to the registry? 1.8 needs JuliaInterpreter 0.9.11 due to JuliaDebug/JuliaInterpreter.jl@5a39c51 which got backported. |
|
Just to say: the original issue I reported still is there. |
|
@fingolfin Does it persist if you remove Revise and add it again? In the report above, your Revise is 3.3.2; latest version is 3.3.3 Also, my JuliaInterpreter did not update to 0.9.11 until I removed and re-added Revise (double checked my Manifest.toml to ensure that the Interpreter had updated). |
George9000
added a commit
to George9000/General
that referenced
this issue
Mar 17, 2022
|
@giordano After forking the registry, I made the start of a Compat.toml edit for JuliaInterpreter. Would you take a look and comment? |
|
Yes it persists. |
Now I know, but I didn't until this message. I'm helping out @George9000 preparing the pull request, but I wish package maintainers did this more proactively instead of waiting for users to crash on the issues they know are there. |
|
Note that anyone should be able to reproduce the crash with the instructions I gave. But here's a fresh backtrace, for your convenience: |
|
Looking at the JuliaInterpreter code on the callstack, we are at some point executing if isanonymous_typedef(stmt)
lastpc = pc = step_through_methoddef(recurse, frame, stmt) # define an anonymous functionand this percolates down into elseif isa(lhs, Symbol)
Core.eval(moduleof(code), :($lhs = $(QuoteNode(rhs))))The debugging statements I enabled are these (in show_stackloc(frame)
@show nodeUnfortunately it just prints a TON of info which I mostly can't make much sense of. But perhaps someone who knows JuliaInterpreter better either can figure out something from this, or can suggest some other things to try (or they can just try it themselves, after all, all that's necessary to do so is available to everyone, this is pure open source code :-) ). |
giordano
added a commit
to JuliaRegistries/General
that referenced
this issue
Mar 20, 2022
…56805) * Update compatibility with Julia version 1.8 see timholy/Revise.jl#675 (comment) * WIP to decipher what was meant previously. * Apply suggestions from code review Co-authored-by: Mosè Giordano <[email protected]> * Apply suggestions from code review Co-authored-by: Mosè Giordano <[email protected]> * Apply suggestions from code review Co-authored-by: Mosè Giordano <[email protected]> * Apply suggestions from code review Co-authored-by: Mosè Giordano <[email protected]> * Fixed whitespace around hyphens * Further whitespace fixes * Versions.toml contains no version 1.0 Suspect registry_testing.jl compressed == compat test failing because it references Versions.toml, which contains no version 1.0. Thus change spec to "0.9.11-0" which should go up to version 1. * Apply suggestions from code review Co-authored-by: Mosè Giordano <[email protected]> Co-authored-by: Mosè Giordano <[email protected]>
|
I can't say why or how, but the problem does not occur for me anymore in latest Julia 1.8 and 1.9 nightly. I've tried prodding it quite a bit and it's working. No idea what change is responsible, unfortunately. |
|
I think I'm still seeing exactly this error on Julia 1.8.0-rc4 and nightly |
|
@lassepe when you say "exactly" do you mean with the exact same packages and reproducer? Then I would have to check that again :-( |
|
No no, just the same pattern but with my own package: After I revise, I hit the same segfault as you in typemap.c. However, in my case it seems to be related to the fact that I have a the julialup julia binary shadowed with a bash function that loads the correct julia binary based on an environment variable. Somehow, that causes Revise to freak out. I guess this causes julia(launcher) to look for a file at the wrong relative directory (because |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This looks similar to the error in #674 but since it does not occur during loading, but rather when revising, I am not 100% sure they are the same, so I am opening a separate issue for now.
The crash occurs when revising https://github.com/oscar-system/Oscar.jl. Some complicating factors
Here is a sample session:
I'll try and see if I can reproduce it on an x86_64 Linux.
The text was updated successfully, but these errors were encountered: