[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: |
Stefano Stabellini |
Subject: |
Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX |
Date: |
Tue, 12 Jun 2012 13:37:14 +0100 |
User-agent: |
Alpine 2.02 (DEB 1266 2009-07-14) |
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?