--- 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. 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). 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.
so, back to square 1. can you at least trace the program with -debugmsg +wave (and still capture the hanging ?)
Unfortunately, turning -debugmsg +wave on has so far made the problem go away. I'll have another couple of attempts this PM as its been quite intermittant. Also, it occurs to me to try -debugmsg +wave with the (broken) WaitForSingleObject patch I mentioned above.
__________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
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)
--- eric pouech eric.pouech@wanadoo.fr wrote:
ok, so making the wavehdr playback synchronous seems to trigger this bug...
It seems that way. I'll investigate further this PM.
some prior point in the execution. Any tips for rapid location of where it's being stored?
1/ use a bt in winedbg to get back (or in some calls) where the problem occured
Yes, the bt is showing me code in homeworld.exe, which I've disassembled. The offending is a rep stosl to an address recovered from the heap immediately before use. The address being recovered is 0x0, hence the exception.
There are no system calls immediately before it, and I'll need a large amount of time to pick through all the jumps in the preceeding code to find where that value is stored, I've explored the immediate 0x200 bytes of opcodes without sighting a call and 0x100 bytes or so of the callers code. I'm intending to pick through it some more tonight.
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)
I'll try this with the synchronous wodWrite patch too.
__________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
--- eric pouech eric.pouech@wanadoo.fr wrote:
hmmm we should be able to attach to a waiting process (what was the error number you got when
trying
to attach winedbg ?)
error 5. This is the result of ptrace failing IIRC. I had previously been ferreting around in winedbg trying to implement debugmsg, which appears in the help, but isn't in dbg.y or debug.l My first attempt was less than stellar and I found other ways to attack the problem.
__________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
On Tue, 23 Oct 2001, Simon Britnell wrote:
--- eric pouech eric.pouech@wanadoo.fr wrote:
hmmm we should be able to attach to a waiting process (what was the error number you got when
trying
to attach winedbg ?)
error 5. This is the result of ptrace failing IIRC.
I have seen this error too. It seems it happens on Linux kernel 2.4.9 and up. When I switched back to 2.4.5 I stopped having problems.
Also I noticed that when winedbg failed to attach, gdb would fail to attach too. So I would say this does not look like a Wine bug, but more like a Linux kernel bug (or something that changed in an incompatible fashion (in a stable kernel)).
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
I have seen this error too. It seems it happens on Linux kernel 2.4.9 and up. When I switched back to 2.4.5 I stopped having problems.
there's been a security update on ptrace in 2.4.9 when attaching to suid programs... Simon told me his wine wasn't suid, what about yours ? there may also some issues on SMP machines ? are you both lucky SMP boxes users ?
A+
On Wed, 24 Oct 2001, eric pouech wrote:
I have seen this error too. It seems it happens on Linux kernel 2.4.9 and up. When I switched back to 2.4.5 I stopped having problems.
there's been a security update on ptrace in 2.4.9 when attaching to suid programs... Simon told me his wine wasn't suid, what about yours ? there may also some issues on SMP machines ? are you both lucky SMP boxes users ?
Making Wine suid? No way! And I don't have an SMP computer either (plus that was on my laptop). There has to be something else.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux
--- Francois Gouget fgouget@free.fr wrote:
Making Wine suid? No way! And I don't have an SMP computer either (plus that was on my laptop). There has to be something else.
I see that there's a ptrace change in the changelog for Linux 2.4.7 having to do with /proc and core dump permissions. Haven't grabbed the patch and looked into the issue yet.
__________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
--- eric pouech eric.pouech@wanadoo.fr wrote:
there may also some issues on SMP machines ? are you both lucky SMP boxes users ?
No SMP here.
__________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
-
eric pouech -
Francois Gouget -
Simon Britnell