On Tue, 12 Jun 2012, Andreas Färber wrote: > 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,
Does this mean that increasing the timeout caused a busy loop somewhere in the test? But if we set the max timeout value to INT32_MAX doesn't happen? > > 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 So I take that the call graph below repeats itself every 1m? > 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 What is the cause of these errors? > 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. Which system call?