On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote: > (gdb) bt > #0 0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6 > #1 0x00000000004e615a in WaitForSomething ( > pClientsReady=<value optimized out>) at WaitFor.c:228 > #2 0x0000000000446ef2 in Dispatch () at dispatch.c:386 > #3 0x000000000042d205 in main (argc=<value optimized out>, > argv=0x7fffa2ac9218, envp=<value optimized out>) at main.c:397 Okay, this isn't the server actually taking 100% of the CPU (almost certainly), it's before that. If you type 'cont' to resume, and then ^C the gdb process once the CPU goes wild, you should break back to the gdb prompt; _that_'s the backtrace I need. Of course, you might not, in which case debugging this gets a bit harder. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
