extern crate inside a function scope dependent on that crate causes a stack overflow #87932
Assignees
Labels
C-bug
Category: This is a bug.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
P-high
High priority
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
echeran
added
C-bug
|
Your compiler is "very" (3 versions behind) old. There should be no reason to pin to such an old compiler, unless you're using a very specific nightly version, which you aren't. This error however does also occur on latest stable (1.54.0) as well as nightly. So, ... @rustbot modify labels: regression-from-stable-to-stable I-crash -I-ICE Stable and nightly outputs are different though: (See #87932 (comment) for explanation) stablenightly |
rustbot
added
regression-from-stable-to-stable
|
This is causing the overflow: pub struct Up;
impl<'de> serde::Deserialize<'de> for Up {
fn deserialize<D>(_: D) -> Result<Self, D::Error>
where
D: serde::Deserializer<'de>,
{
const _A: () = {
extern crate serde as _serde; // maybe this one causing the overflow?
};
Ok(Up)
}
}
fn main() {}Trying to get rid of serde Bisecting shows that even a 2018-06-01 (1.28.0-nightly) will overflow. For reference, here's a code that a user would write, therefore I think this should be P-High pub struct UnicodePropertyV1 {}
impl<'de> serde::Deserialize<'de> for UnicodePropertyV1 {
fn deserialize<D>(_: D) -> Result<Self, D::Error>
where
D: serde::Deserializer<'de>,
{
#[derive(serde::Deserialize)]
enum Field {}
todo!()
}
}The workaround is to move the |
rustbot
added
I-crash
@hellow554 Please don't respond to issues in this way. There are plenty of reasons to pin compiler versions like that, it's not a good idea to presume that someone has no reason to do a thing, and in the case of this issue it seems extraneous. The reduced testcase is appreciated, however! |
|
@echeran note that adding the use declaration is not the source of the bug; the use declaration uncovers the bug because without the @hellow554's reduced testcase also runs on the playpen if needed, btw! |
Manishearth
changed the title
Manishearth
changed the title
Manishearth
changed the title
|
For reference: The small error went away with #80182, which seems fine and dandy because that's whats the PR is supposed to do. So there's nothing wrong with the different outputs of stable and nightly :) |
|
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-high |
rustbot
added
P-high
|
I believe I managed to hit this specific crash while working on Rust-LV2 (this is the WIP commit where I first encountered that crash), however, this project does not depend on Serde. I investigated further, and managed to make a complete minimal test case here, here's the gist of it (in src/lib.rs) : use mylib::{FooTrait, LibFoo};
struct Foo;
impl FooTrait for Foo {
fn foo() {
// The main offender: using extern crate inside the impl of a trait exposed by that same crate.
extern crate mylib as _mylib;
}
}
// An innocent bystander trait impl. It is not necessary to trigger the stack overflow,
// but having the same 'extern crate' declaration in it *prevents* it.
impl Clone for Foo {
fn clone(&self) -> Self {
// Uncomment the following, and it works again.
// NOTE: This alone, without the 'extern crate' in the other impl, does not trigger the stack overflow.
// extern crate mylib as _mylib;
Foo
}
}
// Either remove the pub, or change the return type, and it works again.
// Note: either having this as pub, or having a #[no_mangle] attribute triggers the stack overflow
pub fn exposed_lib_foo() -> LibFoo {
// NOTE: removing/changing this value to another type here causes the correct type error
// and does not trigger the stack overflow (yet?)
LibFoo
}This cannot be reproduced solely in the playground without Serde, as it requires a multiple-crate setup. This project has a main crate and a single The points for reproducing the issue in a project are the following:
The common denominator with Serde here is the ❯ cargo build
Compiling rustc_repro_87932 v0.1.0 (/home/adrien/Projects/RustAudio/rustc_repro_87932)
thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: could not compile `rustc_repro_87932`
Caused by:
process didn't exit successfully: `rustc --crate-name rustc_repro_87932 --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=0af247fb9f5226ff -C extra-filename=-0af247fb9f5226ff --out-dir /home/adrien/Projects/RustAudio/rustc_repro_87932/target/debug/deps -C incremental=/home/adrien/Projects/RustAudio/rustc_repro_87932/target/debug/incremental -L dependency=/home/adrien/Projects/RustAudio/rustc_repro_87932/target/debug/deps --extern mylib=/home/adrien/Projects/RustAudio/rustc_repro_87932/target/debug/deps/libmylib-8a9782bb2f662999.rmeta --extern mylib_sys=/home/adrien/Projects/RustAudio/rustc_repro_87932/target/debug/deps/libmylib_sys-423bf155b0053619.rmeta` (signal: 6, SIGABRT: process abort signal)And here's my I know nothing about
Hope this helps! 🙂 |
eddyb
changed the title
|
I remember this, it is an old issue - #55779. |
|
Ah, right, that got lost in the chaos of Rust 2018 + all the |
|
A different reproducer (one above will stop working soon; probably). $ cat a.rs
pub trait Deserialize {
fn deserialize();
}
$ cat b.rs
pub struct A {}
impl a::Deserialize for A {
fn deserialize() {
extern crate a as _a;
}
}
fn main() {
A::deserialize();
}
$ rustc --crate-type=lib --edition=2018 a.rs
$ rustc --crate-type=bin --edition=2018 b.rs -L. --extern a |
|
Finally found some time for this, some notes:
|
|
Also, I don't recall seeing #55779 (comment) - seems like that would be the correct fix for the stack overflow, whereas the priority thing is more of an "aesthetic" fix. EDIT: this turns out not to be that simple, see #55779 (comment). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been working on a branch where I've made some refactoring changes and I'm working through cargo check errors/warnings/etc. now. Unexpectedly, one of the errors was from rustc mentioning "overflowed the stack":
Code
To reproduce:
uniset-zerovec-rustc-bugin the repoecheran/icu4xcd icu4xcd components/unisetcargo check --testsMeta
rustc --version --verbose:Error output
Backtrace N/A.
The text was updated successfully, but these errors were encountered: