We have a long-running and complicated PHP daemon, and at one point it got into a state where the process was using 100% of the CPU, but it wasn't making any syscalls (strace -p listed nothing).

Using gdb we saw this state:

(gdb) where
#0 xdebug_llist_empty (l=0x2f4fe90, user=0x0) at /tmp/buildd/xdebug-2.1.0/build-php5/xdebug_llist.c:173
#1 0x00007f3bc0cea2b4 in xdebug_llist_destroy (l=0x2f4fe90, user=0x0) at /tmp/buildd/xdebug-2.1.0/build-php5/xdebug_llist.c:180
0000002 0x00007f3bc0cd5c72 in zm_post_zend_deactivate_xdebug () at /tmp/buildd/xdebug-2.1.0/build-php5/xdebug.c:830
0000003 0x0000000000682742 in ?? ()
0000004 0x000000000068f9e5 in zend_hash_apply ()
0000005 0x0000000000683317 in ?? ()
0000006 0x000000000062ee95 in php_request_shutdown ()
0000007 0x00000000007127e4 in ?? ()
0000008 0x00007f3bc1b01c4d in __libc_start_main () from /lib/libc.so.6
0000009 0x000000000042d4b9 in _start ()

and looking at the variable l we saw this:

(gdb) print *l
$2 = {head = 0x0, tail = 0x0, dtor = 0x7f3bc0cd53e4 <xdebug_stack_element_dtor>, size = 1}

The code for xdebug_llist_empty() and xdebug_llist_remove() (here:
https://github.com/mayflowergmbh/xdebug/blob/master/xdebug_llist.c#L171
and here:
https://github.com/mayflowergmbh/xdebug/blob/master/xdebug_llist.c#L106
respectively) suggests that indeed an infinite loop is possible.

I'm not sure how the variable l got into this state, but it has a tail of 0x0 and a size of 1, which means the remove() function doesn't make it any shorter, but the empty() function thinks it needs to be made shorter. Presumably the code would benefit from an extra check to catch this situation, to be defensive.