more mmtimer questions
jwhite at codeweavers.com
Fri Feb 11 23:09:24 CST 2005
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
> 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
> 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
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.
More information about the wine-devel