Oliver Stieber wrote:
I've had a look through the code and can't spot any problems with managing the linked list which would point to problems with TIME_TimersList but when the crash occurs ptimer != &TIME_TimersList
I looked as well, and couldn't see anything obvious.
The only 'flaw' I saw was that we used the WINMM_IData->cs, when, for logical separation, it seems we should have our own cs. But I can't imagine any way in which that flaw would create the condition you describe.
Some sub process causing heap corruption would explain this.
Also if the we're using a = &TIME_TimersList, a=&(*a)->lpNext and then referencing *a in critical sections doesn't anything that modifies TIME_TimersList or ... lpNext also have to be in a critical section? e.g. TIME_MMTimeStart and TIME_MMTimeStop.
If so should the code be change to copy the values in TIME_TimersList and ..->lpNext instead of referencing them or should it be changed to make sure TIME_MMTimeStart and TIME_MMTimeStop etc.. use critical sections.
For correctness, I agree that the clearing of TIME_TimersList should better be protected by a crit section; I admire your thoroughness on that. I also don't understand why time.c shouldn't have it's own crit sec for the TimersList.
But a case where that could credibly become an issue is hard to imagine. You have to have 1 thread termintating the MM Timer while another thread is simultaneously killing or setting an event. Further, the event loops inside the set and term event loops are pretty tight; it's hard to imagine having just the right magic timing conditions and then also having a context switch occur during the short tight loops.
I guess that's a long way of saying that yes, I think you have identified a flaw in the code, but that I can't imagine any way it's could cause the problem you're seeing.
Cheers,
Jer