Race condition in CTimer::PollKernelTimers #404
Closed
renebarto
started this conversation in
Development
Replies: 3 comments
-
Hi Rene, yes, that's an issue. I fixed it on the develop branch. The KY040 was the only place in Circle, where this could happen, because |
Beta Was this translation helpful? Give feedback.
0 replies
-
This fix is in Circle 46. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thanks Rene
Met vriendelijke groet / Kind regards,
Rene Barto
Op wo 28 feb. 2024 09:40 schreef Rene Stange ***@***.***>:
… This fix is in Circle 46.
—
Reply to this email directly, view it on GitHub
<#404 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQY5NMTEMMWR3POS2MVXWTYV3UQXAVCNFSM6AAAAAA57RBNJ6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMMJVGI2DQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi Rene,
I'm continuing my venture on Circle. I Worked on the KY040 rotary switch, and found that, next to issues with the device itself, it causes a race condition.
When two timers are present, and the first one is deleted in a callback of PollKernelTimers due to a CancelKernelTimer call, the ptr list changes, and then the next pointer which was saved, is no longer correct.
I changed this such that after PollKernelTimers reclaims the spinlock, we start at the beginning of the list again. This way the list is correctly pointed to again
void CTimer::PollKernelTimers (void)
{
m_KernelTimerSpinLock.Acquire ();
#ifndef NDEBUG
pTimer->m_nMagic = 0;
#endif
delete pTimer;
}
I hope this is suffciently clear.
Thanks again, regards,
Rene Barto
Beta Was this translation helpful? Give feedback.
All reactions