Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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 lexing & 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.heygears.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.heygears.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 lexing & 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-parser Area: The lexing & 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