Hi,
It looks like calls to Drop::drop() are getting removed when using lto = "fat" for a release build. It doesn't seem to occur with lto = "thin" or lto = "no".
I've got a test case here: https://github.com/cstorey/fat-lto-drop-repro, which can be reproduced like this:
: cez@ceri-no-mini; cargo --version; rustc --version; cargo run; cargo run --release
cargo 1.37.0 (9edd08916 2019-08-02)
rustc 1.37.0 (eae3437df 2019-08-13)
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/lto-drop`
About to panic
thread 'main' panicked at '???', src/libcore/option.rs:1034:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Dropping a Droppable
Finished release [optimized] target(s) in 0.00s
Running `target/release/lto-drop`
About to panic
thread 'main' panicked at '???', src/libcore/option.rs:1034:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
: cez@ceri-no-mini;
(more details in the transcript)
For context, I first noticed this in a project where I am using an mpsc::channel to communciate between threads, where a producer thread reads messages from the network, and the main thread saves those to a database.
I was relying on the fact that the Drop implementation for a channel will in effect close the channel, so the main thread can find out that the producer has failed, and so we should kill the process. What I saw instead was the producer thread panicing, but the main thread would never get woken up.
I've seen this on macOS Darwin 17.7.0 x86_64 and Linux 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64.
Hi,
It looks like calls to
Drop::drop()are getting removed when usinglto = "fat"for a release build. It doesn't seem to occur withlto = "thin"orlto = "no".I've got a test case here: https://github.com/cstorey/fat-lto-drop-repro, which can be reproduced like this:
(more details in the transcript)
For context, I first noticed this in a project where I am using an
mpsc::channelto communciate between threads, where a producer thread reads messages from the network, and the main thread saves those to a database.I was relying on the fact that the
Dropimplementation for a channel will in effect close the channel, so the main thread can find out that the producer has failed, and so we should kill the process. What I saw instead was the producer thread panicing, but the main thread would never get woken up.I've seen this on macOS
Darwin 17.7.0 x86_64and Linux5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64.