[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next d
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX |
Date: |
Tue, 12 Jun 2012 14:58:22 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
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