Am 12.06.2012 10:24, schrieb Andreas Färber: > Am 29.05.2012 15:35, schrieb Stefano Stabellini: > The check-qtest-i386 qemu-system-i386 process now hangs at ~98% CPU, > just as with my INT64_MAX hack before. How would I best debug this qtest > scenario, and what should I be looking for? Since my 1.1 patch this is > no longer going through any Cocoa event handling, so the only causes I > can think of are timers and signals...
Might this shed any light? Analysis of sampling qemu-system-i386 (pid 19531) every 1 millisecond Call graph: 2337 Thread_2503 2337 0xffc 2337 start 2337 main 2337 qemu_main 2337 main_loop_wait 2337 qemu_iohandler_poll 2337 tcp_chr_read 2337 qtest_read 2337 memory_region_iorange_write 2337 rtc_change_mon_event 2337 monitor_protocol_event 2337 monitor_json_emitter 2337 monitor_puts 2337 monitor_flush 2177 write 2177 write 92 send_all 81 cerror 57 malloc_zone_malloc 35 __error 35 __error 17 dyld_stub___error 17 dyld_stub___error 5 cthread_set_errno_self 5 cthread_set_errno_self 24 cerror 11 send_all 36 dyld_stub_write 36 dyld_stub_write 24 dyld_stub___error 24 dyld_stub___error 6 cerror 6 cerror 2 __error 2 __error 2337 Thread_2603 2337 _pthread_start 2337 sigwait_compat 2337 sigwait 2337 __sigwait 2337 __sigwait 2337 Thread_2703 2337 _pthread_start 2337 qemu_dummy_cpu_thread_fn 2337 sigwait 2337 __sigwait 2337 __sigwait rtc-test is still blocked by the system() call apparently, and gtester is polling in its main loop. Andreas