Simon Britnell wrote:
--- eric pouech eric.pouech@wanadoo.fr wrote:
after, rereading my old code, there's nothing wrong (at first glance) here some invocations (like close, reset) need to be synchronous (the calling thread blocks until the rendering thread is done with the message), some others (like adding a wavehdr for play back) are asynchronous, hence the difference
I added a WaitForSingleObject late last PM as an experiment. The results were ... interesting.
The first thing I noticed was that my problem attaching to the process went away, ie. winedbg started to work.
hmmm we should be able to attach to a waiting process (what was the error number you got when trying to attach winedbg ?)
The second thing that happened was that the problem I experience went from being intermittant to constant and now also invariably throws a page fault exception (in the same place it intermittantly threw an exception).
ok, so making the wavehdr playback synchronous seems to trigger this bug...
Tracing back from that page fault is proving difficult as the page fault occurs with a value that's been stored on the heap at some prior point in the execution. Any tips for rapid location of where it's being stored? I suspect it's a null return from a wine system call.
well, usually you can: 1/ use a bt in winedbg to get back (or in some calls) where the problem occured 2/ run with -debugmsg +relay to get the return values from some calls (but it is likely that it'll interfere with your program, as the -debugmsg +wave does)