On 2010-10-26, I've been doing the following: cp -a ../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 the second cp's time, and the deadlock thus is not due to the second C-c, 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