pouech-eric at wanadoo.fr
Sat Oct 2 08:44:08 CDT 2004
> I would investigate whether it is supposed to be in the middle of a
> blocking call and under what conditions it should return from it.
I got a look at it.
Basically, what happens is:
- the entry point code just loops onto itself
EntryPoint: jmp EntryPoint
- so, the creator of this program is likely to wait for the child to be
looping on EntryPoint before going any further (wait until init is done,
and entry point is called)
- however, when one thread calls SuspendThread on another thread (which
is in running state), the later thread gets a USR1 signal. The signal
handler for USR1 will wait on the server until the thread is resumed.
But, the address we get in GetThreadContext is the one from where the
thread waits on the server (hence the 0xffffe410 address), not the
address it was suspended from (as it's supposed to be) (the entry point
I don't think it will be easy to fix.
- implement suspend/resume in processes without any specific code. We
dropped that long ago for stability issues (and race condition removal
- cheat for context reading in server while suspended. it will require
some surgery (getting whether we are in the condition of this program,
getting back to the signal handler, getting the signal context from the
stack, grab the real EIP from it). Doable, but very hard to maintain
(code in server, will depend on how signal handlers are written in
ntdll, code will be CPU specific...)
- storing context in server while entering USR1 signal handler (to be
done without races, which will require some more work, as the server
doesn't synchronize with the USR1 handler)
Nice can of worms :-/
More information about the wine-devel