IRC channel logs


back to list of logs

***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
<youpi>restarting exodar
<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>I will keep spelunking
<youpi>jrtc27: exodar is back
<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>apparently no
<AlmuHS>not approval or not request?
<azeem>or not submitted
<youpi>I eventually submitted something, but way after the deadline
<youpi>so didn't get a slot, it was already full
<AlmuHS>next year then