Hide Forgot
since this was caused while debugging stat-prefetch, there is a possibility that the memory corruption caused by stat-prefetch resulting int this bug.
Here is the backtrace: (gdb) info thr 3 Thread 0xb7568b90 (LWP 10066) 0xb7ea679c in nanosleep () from /lib/libc.so.6 * 2 Thread 0xb6d68b90 (LWP 10068) 0xb7f690a4 in __lll_lock_wait () from /lib/libpthread.so.0 1 Thread 0xb7e10ae0 (LWP 10065) 0xb7f94188 in gf_timer_call_cancel (ctx=0x8051008, event=0x80913e0) at ../../../libglusterfs/src/timer.c:125 (gdb) thr 1 [Switching to thread 1 (Thread 0xb7e10ae0 (LWP 10065))]#0 0xb7f94188 in gf_timer_call_cancel (ctx=0x8051008, event=0x80913e0) at ../../../libglusterfs/src/timer.c:125 125 event->prev->next = event->next; (gdb) p event->prev $10 = (struct _gf_timer *) 0x0 (gdb) p *event $11 = {next = 0x80577a0, prev = 0x0, at = {tv_sec = 0, tv_usec = 1}, cbk = 0xb75b8065 <client_ping_timer_expired>, data = 0x8058448} thread 2 is waiting on the same lock held by thread 1. The setup was a simple protocol/client and protocol/server setup with stat-prefetch loaded on it. I was debugging some bug (ls on mount point used to hang) in stat-prefetch when I hit this bug. The operation being done was ls on mount point.