On 2010-10-26, I've been doing the following:
../tmpdir/dump*.o ./ (65 files), changed my mind, hit
C-c, continued with
cp -a ../tmpdir/dump*.o ./ (to preserve timestamps), wondered why this takes
so long, hit
C-c again, then found the FS deadlocked (using no CPU; but
syncfs -s -c wouldn't finish, for example). Judging from the files'
timestamps (after rebooting and
fsck), I would assume that it already hung at
cp's time, and the deadlock thus is not due to the second
but due to the first one.
# gdb /hurd/ext2fs [...] (gdb) set noninvasive on (gdb) attach 177 [...] [New Thread 177.535] Reading symbols [...] (gdb) info threads [all the same from 177.535 down to...] 11 Thread 177.11 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 10 Thread 177.10 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 [doesn't continue with thread 9, but hangs, taking all CPU time]
New GDB instance, again noninvasive, I'm able to continue.
Here are backtraces for threads 1 to 8 and 10 to 535, I didn't succeed to get any information about thread 9 (which thus would probably be the most interesting one...) -- GDB would always hang when accessing it, no matter whether noninvasive mode or not. (Didn't have time to pull the information out of the process' memory manually (how to do that, anyways?), and also didn't have time to continue with debugging GDB itself, but this sounds like a open issue gdb...)
IRC, freenode, #hurd, 2010-10-27
<youpi> thread 8 hung on ports_begin_rpc <youpi> that's probably where one could investigated first <youpi> yes, a lot of threads are hung on that <tschwinge> You mean 0x10b9488, right? <youpi> yes