> I don't think it will be easy to fix. heh yea this sounds like a difficult one. Way beyond me.
On Sat, 02 Oct 2004 15:44:08 +0200, Eric Pouech <[EMAIL PROTECTED]> wrote: > > 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+ > -- James Hawkins