Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards

[Jon Alduan]

Yes, exactly. When removing timer 0, time 1 will be removed instead. Other timers are not affected. If you create a dummy timer 0, there are no more problems (that I can address).

Thank you and looking forward to your feedback.

Jon

El jue, 21 jul 2022 a las 15:04, Peter Maydell (<peter.maydell@linaro.org>) escribió:

On Thu, 21 Jul 2022 at 13:22, Jon Alduan <jon.alduan@gmail.com> wrote:
>
> Hi Peter,
>
> I already did that with my application, here I send you the output of strace you requested using the application delivered by you.

Thanks. There are some clues in there at least. From the
host strace:

26585 14:18:22.936490 write(1, "Remove timer 0 536880\n", 22 <unfinished ...>
26590 14:18:22.936513 <... rt_sigprocmask resumed>NULL, 8) = 0
26591 14:18:22.936542 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1],
<unfinished ...>
26585 14:18:22.936566 <... write resumed>) = 22
26590 14:18:22.936587 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1],
<unfinished ...>
26585 14:18:22.936610 futex(0x905ac, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
26591 14:18:22.936631 <... rt_sigprocmask resumed>NULL, 8) = 0
26585 14:18:22.936651 <... futex resumed>) = 0
26590 14:18:22.936671 <... rt_sigprocmask resumed>NULL, 8) = 0
26591 14:18:22.936691 rt_sigprocmask(SIG_SETMASK, [RT_4],  <unfinished ...>
26585 14:18:22.936715 timer_delete(1 <unfinished ...>
26590 14:18:22.936735 rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
26585 14:18:22.936757 <... timer_delete resumed>) = 0

So the problem seems like we're straightforwardly deleting the wrong host timer,
rather than being something complicated involving race conditions or how
we pass the signal handler the ID value or whatever. I'll see if I can
work out from the code how this might happen...

-- PMM

--

j.A