[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 10:35:30 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
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