[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: +relay output (Was: Baldurs Gate, Todays Snapshot & , CriticalSection wait timeout)
From:       Eric Pouech <Eric.Pouech () wanadoo ! fr>
Date:       1999-06-28 18:40:30
[Download RAW message or body]

Ulrich Weigand wrote:
> 
> mawali@news.icns.com wrote:
> 
> >   Attached is the output of "wine -debugmsg +relay BGMain.exe". There were
> > about 13000 lines between the timeout and assertion failure, so I am
> > attaching the last 25000 lines (about 38K gzipped). The full trace can be
> > found at:
> 
> Hmmm.  This seems to be the interesting part:
[snip]
> So, what seems to happen is that something goes wrong, presumably
> with the DirectDraw code, which causes the app to signal an error
> condition.
> 
> The reason for the deadlock is apparently that the app itself has
> suspended the thread that currently holds the WINMM critical section,
> and thus it deadlocks in timeKillEvent() ...
> 
> But the deadlock occurs only within the cleanup code, so it is *not*,
> as I had originally thought, that the broken deadlock is the *reason*
> for the failed assertion.
> 
> So there are actually two different problems: first of all, why
> does the DirectDraw stuff fail?  I'm not familiar with what DirectDraw
> does, but it would seem there is simply something unimplemented ...
> 
> Secondly, why the deadlock?  It seems that the WINMM critical
> section is held throughout the processing of the timer callback.
> This does not seem to be a good idea ...  The lock should
> probably be released while user code is executed.
> 
> Bye,
> Ulrich

regarding the last part (for deadlock with MM timers) and calling
user callback with crit sect locked, I already have 
a pre-patch that should cure this behavior (note also that an interim
patch for mm timers has been committed this week end - which also
solves some other mm timers dead-locks)

the only issue I have is included in the comment below. So if someone
wishes to comment on it... feel free !

    /* this is a hack...
     * since timeSetEvent() and timeKillEvent() can be called
     * from 16 bit code, there are cases where win16 lock is
     * locked upon entering timeSetEvent(), and then the mm timer 
     * critical section is locked. TIME_MMSysTimeCallback cannot 
     * call the timer callback with the crit sect locked (because 
     * callback may need to acquire Win16 lock, thus providing a 
     * deadlock situation.
     * To cope with that, we just copy the WINE_TIMERENTRY struct
     * that need to trigger the callback, and call it without the
     * mm timer crit sect locked. The bad side of this 
     * implementation is that, in some cases, the callback may be
     * invoked *after* the timer has been destroyed...
     */
 

-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle


=========================================================================

[prev in list] [next in list] [prev in thread] [next in thread]