On Sun, Oct 19, 2014 at 05:53:10PM -0500, Timothy Pearson wrote:
A cursory look at the bactrace indicates the process
is stuck waiting for
I/O. Is the process stuck in D state (i.e. what does "ps aux" say about
it)?
Nope, "ps aux" says S+, but /proc/$(pidof kbuildsycoca)/stat says R;
However, when interrupting it from GDB, I always end up at the same
address, and a small disassembly shows that it is after a syscall
(read), so the interruption seems to interrupt this syscall.
(gdb) x/10i 0x7f462f734979
0x7f462f734979 <__read_nocancel>: mov $0x0,%eax
0x7f462f73497e <__read_nocancel+5>: syscall
=> 0x7f462f734980 <__read_nocancel+7>: cmp $0xfffffffffffff001,%rax
0x7f462f734986 <__read_nocancel+13>: jae 0x7f462f7349b9 <read+73>
0x7f462f734988 <__read_nocancel+15>: retq
0x7f462f734989 <read+25>: sub $0x8,%rsp
0x7f462f73498d <read+29>:
callq 0x7f462f74e370 <__libc_enable_asynccancel>
0x7f462f734992 <read+34>: mov %rax,(%rsp)
0x7f462f734996 <read+38>: mov $0x0,%eax
0x7f462f73499b <read+43>: syscall
read() receives it's file descriptor in RDI, which GDB prints as 10;
and /proc/$(pidof kbuildsycoca)/fd/10 points to
/var/tmp/kdecache-jagged/ksycoca,
which exists, and is empty; it's a regular file, owned by jagged:users,
with access (0644/-rw-r--r--) (no SElinux), which shouldn't be critical
anyway, since kbuildsycoca runs as root.
--
valgrind python -c 'for i in range(1,1): print(i)' 2>&1 | grep error