Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX

["Andreas Färber" <andreas.faerber@web.de>]

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