1 files changed, 45 insertions, 0 deletions
diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn
new file mode 100644
index 00000000..4c5cdb24
--- /dev/null
+++ b/open_issues/ext2fs_deadlock.mdwn
@@ -0,0 +1,45 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+On 2010-10-26, [[I|tschwinge]]'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|bt_1-8]] and [[10 to 535|bt_10-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 [[!taglink open_issue_gdb]]...)