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

thread 'rustc' panicked at 'begin <= end (2 <= 0) when slicing #71471

Closed
dwrensha opened this issue Apr 23, 2020 · 9 comments
Closed

thread 'rustc' panicked at 'begin <= end (2 <= 0) when slicing #71471

dwrensha opened this issue Apr 23, 2020 · 9 comments
Assignees
Labels
A-parser Area: The parsing of Rust source code to an AST. C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-low Low priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@dwrensha
Copy link
Contributor

dwrensha commented Apr 23, 2020

I'm seeing an internal compiler error on the input "\n#!B\n" (found by fuzz-rustc):

$ cat main.rs

#!B
$ rustc main.rs
thread 'rustc' panicked at 'begin <= end (2 <= 0) when slicing `
#!B
`', /rustc/b2e36e6c2d229126b59e892c9147fbb68115d292/src/libcore/str/mod.rs:1920:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.44.0-nightly (b2e36e6c2 2020-04-22) running on x86_64-unknown-linux-gnu

This issue has been assigned to @rcoh via this comment.

@dwrensha
Copy link
Contributor Author

Error is similar to #70677. @rcoh is this possibly related?

@jonas-schievink jonas-schievink added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-prioritize Issue: Indicates that prioritization has been requested for this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 23, 2020
@rcoh
Copy link
Contributor

rcoh commented Apr 23, 2020

Will do a quick investigation and find out

@LeSeulArtichaut
Copy link
Contributor

Backtrace :

stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:515
  12: rust_begin_unwind
             at src/libstd/panicking.rs:419
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:111
  14: core::str::slice_error_fail
             at src/libcore/str/mod.rs:0
  15: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
  16: rustc_parse::lexer::StringReader::next_token
  17: rustc_parse::lexer::tokentrees::TokenTreesReader::parse_all_token_trees
  18: rustc_parse::lexer::tokentrees::<impl rustc_parse::lexer::StringReader>::into_token_trees
  19: rustc_parse::maybe_file_to_stream
  20: rustc_parse::maybe_source_file_to_parser
  21: rustc_parse::new_parser_from_file
  22: rustc_parse::parse_crate_from_file
  23: rustc_session::utils::<impl rustc_session::session::Session>::time
  24: rustc_interface::passes::parse
  25: rustc_interface::queries::Queries::parse
  26: rustc_interface::interface::run_compiler_in_existing_thread_pool
  27: scoped_tls::ScopedKey<T>::set
  28: rustc_ast::attr::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

The error probably originates from:

let text: &str = &self.src[start_src_index..self.end_src_index];

@estebank estebank added the A-parser Area: The parsing of Rust source code to an AST. label Apr 23, 2020
@rcoh
Copy link
Contributor

rcoh commented Apr 23, 2020

@rustbot claim

@rustbot rustbot self-assigned this Apr 23, 2020
@spastorino
Copy link
Member

Assigning P-low as discussed as part of the Prioritization Working Group process and removing I-prioritize.

@spastorino spastorino added P-low Low priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Apr 23, 2020
@LeSeulArtichaut
Copy link
Contributor

Should we add the need-bisection label?

@rcoh
Copy link
Contributor

rcoh commented Apr 23, 2020

this also looks suspicious: https://github.com/rust-lang/rust/pull/71372/files

@rcoh
Copy link
Contributor

rcoh commented Apr 23, 2020

OK, I've determined the root cause. https://github.com/rust-lang/rust/pull/71372/files changes the shebang handling to strip whitespace -- the intention was to strip internal whitespace to fix #70528 , but it's also stripping external whitespace which (I believe) is a bug.

@LeSeulArtichaut LeSeulArtichaut added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Apr 23, 2020
@rust-lang-glacier-bot rust-lang-glacier-bot added the glacier ICE tracked in rust-lang/glacier. label Apr 24, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Apr 28, 2020
Revert rust-lang#71372 ("Fix #! (shebang) stripping account space issue").

While rust-lang#71372 fixed some of the problems `#!`-stripping had, it introduced others:
* inefficient implementation (`.chars().filter(...).collect()` on the entire input file)
  * this also means the length returned isn't always correct, leading to e.g. rust-lang#71471
* it ignores whitespace anywhere, stripping ` # ! ...` which isn't a valid shebang
  * the definition of "whitespace" it uses includes newlines, which means even `\n#\n!\n...` is stripped as a shebang (and anything matching the regex `\s*#\s*!\s*`, and not followed by `[`, really)
* it's backward-incompatible but didn't go through Crater

Now, rust-lang#71487 is already open and will solve all of these issues. But for running Crater, and just in case rust-lang#71487 takes a bit longer, I decided it's safer to just revert rust-lang#71372.

This will also make rust-lang#71372's diff clearer, as it will start again from the original whitespace-unaware version.

r? @petrochenkov
@dwrensha
Copy link
Contributor Author

dwrensha commented May 1, 2020

It looks like this was fixed by #71634, so I think it can be closed.

@dwrensha dwrensha closed this as completed May 1, 2020
rcoh added a commit to rcoh/rust that referenced this issue May 25, 2020
Shebang handling was too agressive in stripping out the first line in cases where it is actually _not_ a shebang, but instead, valid rust (rust-lang#70528). This is a second attempt at resolving this issue (the first attempt was flawed, for, among other reasons, causing an ICE in certain cases (rust-lang#71372, rust-lang#71471).

The behavior is now codified by a number of UI tests, but simply:
For the first line to be a shebang, the following must all be true:
1. The line must start with `#!`
2. The line must contain a non whitespace character after `#!`
3. The next character in the file, ignoring comments & whitespace must not be `[`

I believe this is a strict superset of what we used to allow, so perhaps a crater run is unnecessary, but probably not a terrible idea.
bors added a commit to rust-lang-ci/rust that referenced this issue May 26, 2020
Fix bug in shebang handling

Shebang handling was too agressive in stripping out the first line in cases where it is actually _not_ a shebang, but instead, valid rust (rust-lang#70528). This is a second attempt at resolving this issue (the first attempt was reverted, for, among other reasons, causing an ICE in certain cases (rust-lang#71372, rust-lang#71471).

The behavior is now codified by a number of UI tests, but simply:
For the first line to be a shebang, the following must all be true:
1. The line must start with `#!`
2. The line must contain a non-whitespace character after `#!`
3. The next character in the file, ignoring comments & whitespace must not be `[`

I believe this is a strict superset of what we used to allow, so perhaps a crater run is unnecessary, but probably not a terrible idea.

Fixes rust-lang#70528
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The parsing of Rust source code to an AST. C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-low Low priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants