Reached unreachable code in possible_dirfd_file #13
Labels
bug
Something isn't working
Comments
|
Currently we handle syscalls that use a Is there a way for me to replicate this to investigate further? (for example I want to know which exact syscall caused this, and also what the remaining path string contains) |
|
If you want to replicate it: fn main() {
use rustix::fs::{MemfdFlags, SealFlags};
let name = c"smithay-client-toolkit";
let flags = MemfdFlags::ALLOW_SEALING | MemfdFlags::CLOEXEC;
let fd = rustix::fs::memfd_create(name, flags).unwrap();
let _ = rustixI made a gist. For the real code I hit: |
sectordistrict
added a commit
that referenced
this issue
Mar 24, 2025
|
Thank you for the detailed report, I was very confused why a memfd was being used like this, turns out it wasn't, and our path resolution in |
|
Good news, 5dca7e1 fixed the crash Bad news, I got now an thread 'main' panicked at src/one_line_formatter.rs:3413:30:
called `Option::unwrap()` on a `None` value
stack backtrace:
0: rust_begin_unwind
at /rustc/249cb84316401daf040832cdbb8a45e0f5ab6af8/library/std/src/panicking.rs:695:5
1: core::panicking::panic_fmt
at /rustc/249cb84316401daf040832cdbb8a45e0f5ab6af8/library/core/src/panicking.rs:75:14
2: core::panicking::panic
at /rustc/249cb84316401daf040832cdbb8a45e0f5ab6af8/library/core/src/panicking.rs:145:5
3: core::option::unwrap_failed
at /rustc/249cb84316401daf040832cdbb8a45e0f5ab6af8/library/core/src/option.rs:2015:5
4: core::option::Option<T>::unwrap
at .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:978:21
5: intentrace::one_line_formatter::<impl intentrace::syscall_object::SyscallObject>::one_line_formatter
at ./src/one_line_formatter.rs:3409:44
6: intentrace::syscall_object::SyscallObject::format
at ./src/syscall_object.rs:91:24
7: intentrace::syscall_returned
at ./src/main.rs:410:9
8: intentrace::parent
at ./src/main.rs:264:33
9: intentrace::runner
at ./src/main.rs:122:21
10: intentrace::main
at ./src/main.rs:107:5
11: core::ops::function::FnOnce::call_once
at .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5Altough I think this should be another issue |
|
I'm not sure because it is quite hard to pinpoint where the faulty syscall is, but I think it should be caused here This could maybe the backtrace The SyscallObject causing this is [src/one_line_formatter.rs:3416:33] &self = SyscallObject {
sysno: ppoll,
category: AsyncIO,
skeleton: [
Array_Of_Struct,
Unsigned_Numeric,
Pointer_To_Struct,
Pointer_To_Struct,
Length_Of_Bytes_Specific,
],
result: (
Some(
64,
),
Numeric_Or_Errno,
),
process_pid: Pid(
1315654,
),
errno: None,
state: Entering,
paused: false,
}The problem should be that syscall_objects.rs:875 read_bytes returns the Errno EIO which is not catched |
|
Using this at one_line_formatter.rs:3468 if timeout > 0 {
let timespec = SyscallObject::read_bytes_as_struct::<16, timespec>(
REGISTERS.get()[2] as usize,
self.process_pid as _,
);
self.general_text(", and timeout ");
if let Some(timespec) = timespec {
self.format_timespec(timespec.tv_sec, timespec.tv_nsec);
} else {
self.write_text(
"could not get timeout"
.custom_color(get_thread_local_color!(OUR_YELLOW)),
);
}
} else {
self.general_text(", and ");
self.write_text(
"wait forever".custom_color(get_thread_local_color!(OUR_YELLOW)),
);
}fixed at least the crash for me. Why it cannot read the timespec, I don't know. |
I also can't tell, for now I'll display a blinking error, similar to your workaround Thanks again for the detailed reporting |
sectordistrict
added a commit
that referenced
this issue
Mar 24, 2025
|
Question, does ppoll work for you? I see on all ppoll either immediately or [intentrace: could not get timeout] I think the ppoll is used by the mesa. Possible backtrace |
|
It always tries to read the timeout at 0x4040 and fails, so I think it is reading events from the mesa driver where ptrace cannot read it. Also cannot read the address with gdb. All other addresses are like something 0x7FFF51BCB030. |
sectordistrict
added a commit
that referenced
this issue
Mar 24, 2025
|
One thing that's peculiar to me is that usage of What I did now for struct reading was switch from |
|
sectordistrict
added a commit
that referenced
this issue
Mar 24, 2025
Still the same address, just Errno is now EFAULT FD 1 works |
|
strace output It seems strace can find the timeout, but I cannot find ppoll with fd 1.... Personally I don't think that if sometimes the timeout isn't printed out correctly is a real issue. Also, I think it is quite hard to reproduce (I think you need an AMD GPU + Wayland + maybe specific GPU) |
|
Yeah, my current plan is to leave this until I go through all Async IO syscalls one-by-one in the future, I also want to wait until I refactor helper functions as that would help even more |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I added a dbg! before the unreachable and build in debug, I got for commit (86c22cd):
rustc --version
rustc 1.87.0-nightly (249cb8431 2025-03-12)
intentrace -V
intentrace 0.7.0
The text was updated successfully, but these errors were encountered: