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