ICE: 'failed to get environment variable "\u{103ff}¿\u{1a}\u{0}j\'": data provided contains a nul byte', library/std/src/env.rs:252:29

[Cancelll]

Code

fn main() {
    option_env!(
        "𐏿¿�\0j\'\
 
"
    )
}

Meta

rustc --version --verbose:

rustc 1.54.0-nightly (dbe459ded 2021-06-02)
binary: rustc
commit-hash: dbe459dedd33470f2cb28101157de316caaffa66
commit-date: 2021-06-02
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

Error output

thread 'rustc' panicked at 'failed to get environment variable `"\u{103ff}¿\u{1a}\u{0}j\'"`: data provided contains a nul byte', library/std/src/env.rs:252:29
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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.54.0-nightly (dbe459ded 2021-06-02) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z mir-opt-level=3 -Z new-llvm-pass-manager=yes -Z unsound-mir-opts=yes -Z polonius=yes -Z polymorphize=yes -C debuginfo=2 -C opt-level=3 --crate-type staticlib

query stack during panic:
end of query stack

Backtrace

thread 'rustc' panicked at 'failed to get environment variable `"\u{103ff}¿\u{1a}\u{0}j\'"`: data provided contains a nul byte', library/std/src/env.rs:252:29
stack backtrace:
   0: rust_begin_unwind
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/std/src/panicking.rs:515:5
   1: std::panicking::begin_panic_fmt
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/std/src/panicking.rs:457:5
   2: std::env::_var_os::{{closure}}
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/std/src/env.rs:252:29
   3: core::result::Result<T,E>::unwrap_or_else
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/core/src/result.rs:821:23
   4: std::env::_var_os
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/std/src/env.rs:251:5
   5: std::env::var_os
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/std/src/env.rs:247:5
   6: std::env::_var
             at /rustc/dbe459dedd33470f2cb28101157de316caaffa66/library/std/src/env.rs:215:11
   7: rustc_builtin_macros::env::expand_option_env
   8: rustc_expand::expand::MacroExpander::fully_expand_fragment
   9: rustc_expand::expand::MacroExpander::expand_crate
  10: rustc_interface::passes::configure_and_expand_inner
  11: rustc_interface::passes::configure_and_expand::{{closure}}
  12: rustc_data_structures::box_region::PinnedGenerator<I,A,R>::new
  13: rustc_interface::passes::configure_and_expand
  14: rustc_interface::queries::Queries::expansion
  15: rustc_span::with_session_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.54.0-nightly (dbe459ded 2021-06-02) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z mir-opt-level=3 -Z new-llvm-pass-manager=yes -Z unsound-mir-opts=yes -Z polonius=yes -Z polymorphize=yes -C debuginfo=2 -C opt-level=3 --crate-type staticlib

query stack during panic:
end of query stack

[nagisa]

fn main() {
    option_env!("\0")
}

Simplified. The other malformed-looking bytes don't matter, do they?

[Cancelll]

fn main() {
    option_env!("\0")
}

Simplified. The other malformed-looking bytes don't matter, do they?

You are right, they don't. I should have simplified it before submit.

[inquisitivecrystal]

Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself.

@rustbot claim

[inquisitivecrystal]

Still working on this, but I figured an update may be helpful.

My research indicates that the two characters that are potentially problematic are \0 and =. The work that needs to be done consists of 1) updating the macro expansion functions in compiler/rustc_builtin_macros/src/env.rs to error in these cases; and 2) updating the macro documentation in library/core/src/macros/mod.rs to mention the new errors.

Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium

[fee1-dead]

internals forum discussion

I don't think just adding a check to raise error in these cases would be enough.

The std function shouldn't really panic (from the internals discussion).

Another problem is when the OS supports this kind of environment variable. e.g. A=B as key. env! would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) @inquisitivecrystal, as this must be changes to std which would take a while.

[inquisitivecrystal]

If this is going to be fixed upstream in std in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.

[inquisitivecrystal]

Actually, simple solution: I'll do the std fix. Working on that now.

[DemiMarie]

Was this fuzzer output? If so, which fuzzer were you using @Cancelll?

[Cancelll]

Was this fuzzer output? If so, which fuzzer were you using @Cancelll?

Yes, I am using kira, a work-in-progress fuzzing tool

[DemiMarie]

Was this fuzzer output? If so, which fuzzer were you using @Cancelll?

Yes, I am using kira, a work-in-progress fuzzing tool

Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.

[Cancelll]

Was this fuzzer output? If so, which fuzzer were you using @Cancelll?

Yes, I am using kira, a work-in-progress fuzzing tool

Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.

Yes, actually kira is structure-aware.