Not planned
Description
Code
Problematic Version: rustc 1.83.0 (90b35a6 2024-11-26)
Works on rust rustc 1.82.0 (f6e511e 2024-10-15)
Using my lib, here's a short example causing the segfault.
Issue Demo Requires Submodule!
SegFault
Thread 1 "server" received signal SIGSEGV, Segmentation fault.
alloc::sync::{impl#29}::deref<dyn enginelib::event::EventHandler, alloc::alloc::Global> (self=0x555555d77db0)
at /home/styly/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/sync.rs:2179
2179 &self.inner().data
Rust 1.83 seems just leak. #128778 may be the cause but i can't seem to compile rust at all.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
compiler-errors commentedon Dec 7, 2024
What is the regression here? I don't think you mentioned what the problem actually is.
IGN-Styly commentedon Dec 7, 2024
Compilation happens fine but on execution a segfault happens, which didn't happen on previous versions. My bets are on: #128778 i am currently testing.
IGN-Styly commentedon Dec 8, 2024
@compiler-errors I Just made my lib oss, and updated issue to have code to recreate the bug.
apiraino commentedon Dec 9, 2024
@IGN-Styly can you please update your report adding how do you build your library. That would help in reproducing more quickly the issue. Thank you.
jieyouxu commentedon Dec 9, 2024
More specifically, can you also make your example self-contained, e.g. in a repo, so that we can confirm what we try to run is the same as what you try to run?
IGN-Styly commentedon Dec 9, 2024
yes will do asap
IGN-Styly commentedon Dec 9, 2024
Have Updated to include a repo to easily recreate the bug.
cyrgani commentedon Dec 9, 2024
Can reproduce, working on minimizing this.
@rustbot label: -S-needs-repro -S-needs-info
3 remaining items
cyrgani commentedon Dec 9, 2024
https://github.com/cyrgani/issue-134014 is a reduction that still keeps the original behavior of not segfaulting on 1.82 but on 1.83 and needs no external crates. However, removing the simple
println!("cursed");
line in the repro causes it to segfault on 1.82 as well.Additionally interesting is that the original unmodified code segfaults on 1.80 and below too, but not on 1.81.
IGN-Styly commentedon Dec 10, 2024
is it haunted?( i know my code is shitty but i haven't found a better solution) might be lifetime related, and if you dont mind ill add the minimized repro into the inial repo.
workingjubilee commentedon Dec 10, 2024
I am removing the regression status because based on @cyrgani's report it seems very likely that what happened here is difficult to classify as a regression.
lukas-code commentedon Dec 10, 2024
@cyrgani's minimal repro from #134014 (comment) has UB by reading from a vtable that is located in a dynamic library that has been dynamically unloaded.
The reduced example looks roughly like this:
where
enginelib
is a library that has a trait implengine_core
is a dynamic library that exports a function like this:and
engine
is an executable that dynamically loads (and unloads!)engine_core.so
:This works in 1.82, because for some reason the
dlclose
doesn't actually cause the dynamic library to be unloaded on that version. I haven't investigated why this happens.Anyway, I'm inclined to say that this is probably not a compiler bug: When dynamic libraries are dynamically unloaded, then global variables (including vtables!) are suddenly not so global anymore, and it is the responsibility of the programmer to ensure that they aren't used after they have been freed.
jieyouxu commentedon Dec 10, 2024
Thanks for the analysis @lukas-code and the reduction @cyrgani! I'm going to close this as not-a-compiler-bug.