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