Dimitrie O. Paun wrote:
On Thu, Nov 04, 2004 at 08:02:24PM +, Mike Hearn wrote:
Long term the plan is to use SIGUSR2 to implement SetThreadContext, with
SIGUSR1 uploading the sigcontext to the server for GetThreadContext like
in the patch.
That requires modifying DOSVM so it doesn't use SIGUSR2
> Sorry if I'm way off (haven't looked at the problem myself), but can't we
> include a command-byte or so with the payload (in the case the context), so
> we can multiplex multiple requests on the same signal?
Well, that's what I meant by figuring it out. As far as I know signals
cannot contain p
On Thu, Nov 04, 2004 at 08:02:24PM +, Mike Hearn wrote:
> Long term the plan is to use SIGUSR2 to implement SetThreadContext, with
> SIGUSR1 uploading the sigcontext to the server for GetThreadContext like
> in the patch.
>
> That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring
Hi,
On Thu, Nov 04, 2004 at 08:02:24PM +, Mike Hearn wrote:
> This does leave the question of OpenGL/D3D thread affinity open, the plan
> was to use a signal for that but we only have 2!
If we only have two signals (SIGUSR1, SIGUSR2), then a good idea would be
to implement some sort of signal
On Thu, 04 Nov 2004 14:11:08 +, Mike Hearn wrote:
> Well, don't leave me in suspense, show me where they are! :)
I talked on IRC to Alexandre about this. The first race he was thinking of
is not a problem with this patch as Get/SetThreadContext loop until the
context is uploaded. The second ra
On Wed, 03 Nov 2004 21:00:14 -0800, Alexandre Julliard wrote:
> Actually I already did a similar hack in the Crossover tree; it's not
> merged because it's full of races (which at first glance seems to be
> the case with yours too).
Well, don't leave me in suspense, show me where they are! :)
I t
Mike Hearn <[EMAIL PROTECTED]> writes:
> I've attached a patch which fixes this for me. It's not too tricky, if
> you want me to explain it though I'm happy to do so.
>
> This feels like the sort of patch Alexandre will rewrite to his liking
> anyway :)
Actually I already did a similar hack in th
>> - 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)
I've implemented this in my local tree, and it works fine: Easy CD-DA
gets further now. It is still being n
ptrace uses SIGSTOP on the child process, so it boils down to the first
item in the list
Could you elaborate on the stability issues it caused please? SIGSTOP
seems to be the most straightforward mapping of SuspendThread.
thanks -mike
Mike Hearn a écrit :
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 i
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 th
Maybe if we do this right, we can get rid of the racy looking loop
at the top of test_SuspendThread() in dlls/kernel/tests/thread.c ...
or is that loop needed on Windows, too?
I think it's needed. The loop is only here to wait for the child to call
actually SuspendThread. So, it's just about being
Eric Pouech ([EMAIL PROTECTED]) wrote:
> ...
But, the address we get in GetThreadContext is the one from where the
thread waits on the server (hence the 0xe410 address), not the
address it was suspended from (as it's supposed to be)
I don't think it will be easy to fix.
Possible ideas:
...
-
> 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 shou
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
Mike Hearn wrote:
On Thu, 2004-09-30 at 17:37, James Hawkins wrote:
err:thread:GetThreadContext Eip: e410
err:thread:GetThreadContext Eip: e410
err:thread:GetThreadContext Eip: e410
err:thread:GetThreadContext Eip: e410
and that is repeated until I terminate it.
Wierd. That
On Thu, 2004-09-30 at 17:37, James Hawkins wrote:
> err:thread:GetThreadContext Eip: e410
> err:thread:GetThreadContext Eip: e410
> err:thread:GetThreadContext Eip: e410
> err:thread:GetThreadContext Eip: e410
>
> and that is repeated until I terminate it.
Wierd. That value of EIP
oops after moving the ERR() to after the server RPC, this is what we get:
err:thread:GetThreadContext Eip: e410
err:thread:GetThreadContext Eip: e410
err:thread:GetThreadContext Eip: e410
err:thread:GetThreadContext Eip: e410
and that is repeated until I terminate it.
On Thu, 30
On Thu, 2004-09-30 at 16:33, James Hawkins wrote:
> I added the ERR output to GetThreadContext and the results are:
>
> err:thread:GetThreadContext Eip: 0
> err:thread:GetThreadContext Eip: 0
> err:thread:GetThreadContext Eip: 0
> err:thread:GetThreadContext Eip: 0
>
> and this continues until I
I added the ERR output to GetThreadContext and the results are:
err:thread:GetThreadContext Eip: 0
err:thread:GetThreadContext Eip: 0
err:thread:GetThreadContext Eip: 0
err:thread:GetThreadContext Eip: 0
and this continues until I break out of the program with ctrl-c.
On Thu, 30 Sep 2004 15:27:
> I modified Sleep to do an ERR("USING MODIFIED SLEEP!\n") and then
> added the check for timeout==64, set it to 3000, but it still calls
> sleep over and over again without any progress. I even took out the
> check for timeout==64 and just timeout to 3000 for the second test,
> but I get the same
On Wed, 29 Sep 2004 12:38:32 -0400, James Hawkins <[EMAIL PROTECTED]> wrote:
> > Let's engage on a little log analysis shall we? This is something that
> > just comes with practice ...
>
> Wow...very impressive.
>
> > Here's an idea. Hack the Sleep() call like this:
> >
> > if (delay == 64) delay
> Let's engage on a little log analysis shall we? This is something that
> just comes with practice ...
Wow...very impressive.
> Here's an idea. Hack the Sleep() call like this:
>
> if (delay == 64) delay = 3000;
ok I will try this out and get back to you on what happens.
On Wed, 29 Sep 2004
I think Marcus is right, this looks like copy protection.
Let's engage on a little log analysis shall we? This is something that
just comes with practice ...
Just after the program starts, it does a CreateProcess:
0023:Call kernel32.CreateProcessA(406cd2f0 "C:\\Program Files\\Easy CD-DA Extractor
On Mon, Sep 27, 2004 at 01:45:29PM -0400, James Hawkins wrote:
It is doing:
> 0025:Starting process L"C:\\Program Files\\Easy CD-DA Extractor 7\\ezcddax.exe"
> (entryproc=0x
761060)
But "0025" never appears again (just as you pressed ctrl-c at the end).
So this ezcddax.exe hangs somewhere, per
25 matches
Mail list logo
