Am 12.06.2012 14:37, schrieb Stefano Stabellini: > 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?
Note that this is solely about qtest, which I never saw working (probably didn't try before). Regular system emulation seemed to work just fine. Where would I try INT32_MAX for comparison? >>> 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? Copy&paste from Mac OS X v10.5.8 process analysis. >> 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? Dunno... It looks weird that qtest_read() would be calling memory_region_iorange_write(). >> 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? Was summarizing the two other processes' analysis report call graphs. `git grep "system("` makes this one likely: tests/libqtest.c: ret = system(command); I'm still lacking substantial understanding of how qtest actually works... My impression is that the libqtest code is being used in the *-test executables, launching a regular QEMU process put into qtest mode via -machine accel=qtest and communicating via the -qtest socket. If that is so, then my guess about the above error is that the monitor socket is not being drained...? Andreas