From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../ext2fs_deadlock.mdwn | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 service_solahart_jakarta_selatan__082122541663/ext2fs_deadlock.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/ext2fs_deadlock.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/ext2fs_deadlock.mdwn b/service_solahart_jakarta_selatan__082122541663/ext2fs_deadlock.mdwn new file mode 100644 index 00000000..23f54a4a --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/ext2fs_deadlock.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010, 2012 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]]...) + + +# IRC, freenode, #hurd, 2010-10-27 + + thread 8 hung on ports_begin_rpc + that's probably where one could investigated first + yes, a lot of threads are hung on that + You mean 0x10b9488, right? + yes -- cgit v1.2.3