Eric Pouech <[EMAIL PROTECTED]> writes:
> After looking at this, it's not really the debugger which is to blame...
> what happens is a nice deadlock in the debugger/process creation code
>
> what happens is as follows:
> - the debugger D creates a new process P using CreateProcess
> - upon P creation, several interactions occur between creator of P
> (aka process D), P itself and the server (with events and such)
> - more precisely, D waits until P has reached some stage in init (mainly
> after main module for P (and all its dependancies, including here opengl32)
> has been loaded
> - if an exception occurs before, P sends an exception to the server, which
> lets P wait until D grabs it
> - but D is waiting for P creation to be completed (still in CreateProcess
> code)
>
> hence the deadlock
I don't think we can use the debugger in the init phase. We cannot
send exception events before we have sent the create process event,
and this happens after the dlls are loaded. I think the best way to
solve the deadlock is to delay calling SIGNAL_Init until after the
process has finished loading, so that if it crashes during startup we
get a nice coredump... but in any case we cannot use the builtin
debugger (gdb should work though, we haven't yet created threads at
this point).
--
Alexandre Julliard
[EMAIL PROTECTED]
