***Server sets mode: +nt
<jrtc27>youpi: exodar is angry at me; I was stepping through code going in and out of __GI___spin_lock and then the whole system locked up :/ <youpi>there is one thing problematic with single-step, it's entering a critical section glibc: from then on signals etc. can't work so gdb can't work any more, but that wouldn't freeze the whole system <jrtc27>I could intermittently get a shell and tried to kill -9 bits, but then everything locked up... :P <youpi>possibly it's the proc server which got confused <youpi>that usually makes things go mayhem <youpi>that can probably be debugged with a subhurd <jrtc27>that's plausible; htop blocked when I had a shell <jrtc27>ps worked but maybe my grep sent SIGPIPE early enough... <jrtc27>btw, off the top of your head, can you think of any reason why `open64(path, O_WRONLY | O_NDELAY);` would return -1 and leave errno as ENOSYS <jrtc27>(don't yet know if that's because errno is mistakenly left alone or because it's actually getting ENOSYS) <youpi>Mmm, no. That would come from glibc itself, not hurd <jrtc27>yeah hence why I was deep in the glibc call stack :) <jrtc27>if it makes a difference, the file in question is a FIFO, just to make things more fun <jrtc27>ah, the ENXIO case for "O_NONBLOCK | O_WRONLY is set, the named file is a FIFO, and no process has the FIFO open for reading." <jrtc27>gdb just doesn't understand TLS enough to print the right errno ***Emulatorman___ is now known as Emulatorman
<AlmuHS>youpi: are there any Hurd talk in FOSDEM this year? <youpi>I eventually submitted something, but way after the deadline <youpi>so didn't get a slot, it was already full