1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
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
<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
|
