Conversation

... not every day do i get an opportunity to trace a bug from an application i was simply trying to use, all the way through hyper, tokio, mio, and std::net_imp into some deeper abyss what possessed the environment i'm running to return -ENOENT from getsockname()? i have no idea

179

Catherine

@whitequark

Jan 24, 2021

i was trying to play a video game. you know. have fun. get some rest

100

Catherine

@whitequark

Jan 24, 2021

instead i got (with the bind() call succeeding on strace): > thread 'tokio-runtime-worker' panicked at 'error binding to 0.0.0.0:8082: error creating server listener: File not found. (os error 2) which makes absolutely no sense however you may look at it

Catherine

@whitequark

Jan 24, 2021

naturally, if i use `strace --trace=getsockname -Z` then the getsockname call succeeds. what the fuck

Replying to

wait what how does that even

Replying to

turns out the gethostname syscall just succeeds. it's ... something in the rust code?

Replying to

that's gotta be some race condition shit, right? how else do you end up with a load bearing strace

Replying to

and

It's pretty common. It prevents programs from screwing themselves over with ptrace because they fail to attach. Some programs think it's a good idea to ptrace themselves for one reason or another and screw it up in a way that causes races, screwed up signal handling, etc.

Replying to

and

Not relevant here but this is an actual thing. It can also hide race conditions as you suggested since it causes serialization for system calls and other events it's catching. Seen this kind of thing quite a lot. Try to debug something and the race condition stops happening.

5:31 AM · Jan 24, 2021Twitter Web App

Replying to

and

ptrace is also definitely a strong contender for worst *nix API. Maybe debuggers could actually be good if the OS had usable, working APIs. It screws up threads, signals and sub-processes. Causes extra system call interrupts too. PTRACE_SEIZE makes it less bad on Linux.