Closed
Description
When setting the directory to persist doctests to if an UNC path is used on windows there's a segfault.
The offending setting of persist-doctests: --persist-doctests \?\C:\Users\danie\Documents\doc_coverage\target\doctests
. cargo-tarpaulin sets this programatically using a path it gets for the target directory from cargo-metadata. The path from cargo-metadata is an UNC path and this then causes a segfault. I'm going to detect UNC paths in my code and remove the \?
on windows, but I felt this warrants a bug report as someone else will hit it eventually. Also, I'm not sure if other parts of the compiler fall prey to this issue?
Compiler version is: the latest nightly (1.64.0-nightly 8308806 2022-06-28)
The stack trace:
Compiling doc_coverage v0.1.0 (C:\Users\olly\Documents\personal\tarpaulin\tests\data\doc_coverage)
Finished test [unoptimized + debuginfo] target(s) in 0.63s
Doc-tests doc_coverage
thread 'rustc' panicked at 'Couldn't create directory for doctest executables: Os { code: 123, kind: InvalidFilename, message: "The filename, directory name, or volume label syntax is incorrect." }', src\librustdoc\doctest.rs:1007:18
stack backtrace:
0: 0x7ff93bd49fff - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0f1df7adb4896e85
1: 0x7ff93bd8426a - core::fmt::write::h2c1465c3e28c942a
2: 0x7ff93bd3c4f9 - <std::io::IoSliceMut as core::fmt::Debug>::fmt::hb1a2ed0de2369014
3: 0x7ff93bd4d8eb - std::panicking::default_hook::haee1d1aa39f2f900
4: 0x7ff93bd4d56b - std::panicking::default_hook::haee1d1aa39f2f900
5: 0x7ff92d9570c6 - rustc_driver[ea556dad31370c9]::pretty::print_after_hir_lowering
6: 0x7ff93bd4e092 - std::panicking::rust_panic_with_hook::h721a2416feebc9e2
7: 0x7ff93bd4de2d - <std::panicking::begin_panic_handler::StrPanicPayload as core::panic::BoxMeUp>::get::h95f3ebdac3a8ee16
8: 0x7ff93bd4ac37 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0f1df7adb4896e85
9: 0x7ff93bd4db09 - rust_begin_unwind
10: 0x7ff93bdba4c5 - core::panicking::panic_fmt::h89f1da2c4ab0f5ba
11: 0x7ff93bdba643 - core::result::unwrap_failed::hb29f524c99360ed5
12: 0x7ff7562b455e - <unknown>
13: 0x7ff7561419fb - <unknown>
14: 0x7ff7562b6334 - <unknown>
15: 0x7ff7562b5a3d - <unknown>
16: 0x7ff7560726ae - <unknown>
17: 0x7ff7560f4447 - <unknown>
18: 0x7ff7560311d0 - <unknown>
19: 0x7ff75612a1ef - <unknown>
20: 0x7ff75603357a - <unknown>
21: 0x7ff75628739a - <unknown>
22: 0x7ff75609f719 - <unknown>
23: 0x7ff93bd5e61c - std::sys::windows::thread::Thread::new::h544ff616ee18698f
24: 0x7ff9a7b87034 - BaseThreadInitThunk
25: 0x7ff9a84e2651 - RtlUserThreadStart
Activity
pinkforest commentedon Jun 30, 2022
This panic is also triggered in Linux if e.g. trying to write into a directory that the user has no permission to write.
I PR'd #98708 fix to change the unwrap to more orderly panic and relaying the underlying error detail via eprintln!
~/gg/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc --test -Z unstable-options --persist-doctests /tmp/foobar main.rs
Couldn't create directory for doctest executables: Permission denied (os error 13)
instead of:
xd009642 commentedon Jun 30, 2022
The lack of ICE is definitely nicer, but this still won't handle UNC paths on windows will it? Which is the main issue I personally have with the code
pinkforest commentedon Jun 30, 2022
That's a problem for std::fs::create_dir_all(&path) me thinks has to be fixed there
xd009642 commentedon Jun 30, 2022
Makes sense looking at the code, should I raise another issue for the libs team?
pinkforest commentedon Jun 30, 2022
Actually, yes it would be great to raise another issue targeting std::fs::create_dir_all - as it is wider issue. you are right. Thanks!
the8472 commentedon Jun 30, 2022
We call those verbatim paths and they have to start with
\\?\
, not\?\
.So isn't this an issue with the tool generating an incorrect argument?
xd009642 commentedon Jun 30, 2022
So the paths are weirding me out (I normally only use linux), because they seem to sometimes print differently given different display methods. It shows up as
\\?\
printing the path in my rust code before making the env var, and if I print the rustdocflags I'm setting it's correct. But if I dopath.starts_with(r#"\\?\");
it returns false, I have to do.display().to_string().starts_with(r#"\\?\");
for it to return true. I'll raise the other issue and after work look into it more properly try to make a better MRE for windowspinkforest commentedon Jun 30, 2022
@xd009642 do you mind changing title s/UNC/invalid/ to address the panic on this issue, thanks! :)
[-]Panic if UNC path used for -Z persist-doctests on windows[/-][+]Panic if invalid path used for -Z persist-doctests on windows[/+]pinkforest commentedon Jun 30, 2022
@xd009642 also please remove s/on windows// thanks a lot 👍
xd009642 commentedon Jun 30, 2022
Done, and I realised what was wrong with the path, it's correct in the code, it's just when it got set into the environment variable it seems it needed the first slash to be escaped and that caused the invalid path (so no issues in std::fs need fixing)
[-]Panic if invalid path used for -Z persist-doctests on windows[/-][+]Panic if invalid path used for -Z persist-doctests [/+]pinkforest commentedon Jun 30, 2022
@rustbot claim
@rustbot label +I-ICE +T-RUSTDOC
8 remaining items