ez-cdda sleep

[Eric Pouech]

> 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 
address).

I don't think it will be easy to fix.

Possible ideas:
- implement suspend/resume in processes without any specific code. We 
dropped that long ago for stability issues (and race condition removal 
as well)
- 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 :-/

A+