Am 29.05.2012 15:35, schrieb Stefano Stabellini: > qemu_rearm_alarm_timer partially duplicates the code in > qemu_next_alarm_deadline to figure out if it needs to rearm the timer. > If it calls qemu_next_alarm_deadline, it always rearms the timer even if > the next deadline is INT64_MAX. > > This patch simplifies the behavior of qemu_rearm_alarm_timer and removes > the duplicated code, always calling qemu_next_alarm_deadline and only > rearming the timer if the deadline is less than INT64_MAX. > > Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Tested-by: Andreas Färber <andreas.faer...@web.de> This resolves the assertion I had previously reported. 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... Andreas
