More debugger quesions

[Robert Lunnon]

On Friday 15 July 2005 02:44, Eric Pouech wrote:
> Robert Lunnon a écrit :
> > Well we are getting somewhere
> >
> > When my test application segfaults the debugger attaches and runs through
> > a number of debug events eventually ariving at a segfault
> >
> > strace:winedbg:dbg_handle_debug_event 00000008:00000009: loads DLL c:
> > \windows\system\imm32.dll @7f440000 (0<0>)
> > trace:winedbg:dbg_handle_debug_event 00000008:00000009: exception
> > code=80000003
> >
> > Now I added some instrumentation and find the following happens IE
> >
> > trace:winedbg:dbg_handle_debug_event Continue on first exception is true
> > trace:winedbg:dbg_handle_debug_event Breaking switch
> > trace:winedbg:dbg_handle_debug_event Call ContinueDebugEvent
> > trace:winedbg:dbg_handle_debug_event Continuing executio
> > trace:winedbg:dbg_main_loop Wait for next debug event...
> >
> > In this code at the top of dbg_main_loop
> >     if (dbg_curr_process)
> >         dbg_printf("WineDbg starting on pid 0x%lx\n", dbg_curr_pid);
> >
> >     /* wait for first exception */
> >     while (WaitForDebugEvent(&de, INFINITE))
> >     {
> >         WINE_TRACE("Calling handle_debug_event 2\n");
> >         if (dbg_handle_debug_event(&de)) {WINE_TRACE("Event
> > handled\n");break;}
> >     WINE_TRACE("Wait for next debug event...\n");
> >     }
> >
> >
> > Problem is that the client program is stopped, probably on a segfault
> > trace because I enable tracing (stops) on all machine faults and signals
> > when I attached it (this allows my replacement for wait4 to find out if a
> > fault or signal happened in the debuggee). Everything deadlocks then
> > since the debugger never continues the program after the exception (Or
> > perhaps the wineserver never gets a message to restart it)
> >
> > Perhaps I don't understand the semantics of PTRACE wait4 interactions.
> > Should I just let the app trap machine faults ?
>
> a couple of questions:
> - when you call ContinueDebugEvent, did you change the causes that caused
> the crash (from the debugger) ? If not, it should segfault again (but I
> don't know what happens)
> - after you called ContinueDebugEvent, the debuggee should be restarted. It
> isn't the case, so I'd start looking at ContinueDebugEvent in the server so
> see what fails (you may want to start with breakpoints instead of seg
> faults, as it may be easier to handle - except for some kludges -> see
> winedbg/break.c, when incrementing / decrementing EIP)
>
> HTH

OK I am back onto the trail but the code doesn't make sense to me
Continue Debug Event Sends a message continue_debug_event to the wineserver 
which ends up in this function in thread.c

static int send_thread_wakeup( struct thread *thread, void *cookie, int 
signaled )
{
    struct wake_up_reply reply;
    int ret;

    reply.cookie   = cookie;
    reply.signaled = signaled;
    if ((ret = write( get_unix_fd( thread->wait_fd ), &reply, sizeof(reply) )) 
== sizeof(reply))
        return 0;
    if (ret >= 0)
        fatal_protocol_error( thread, "partial wakeup write %d\n", ret );
    else if (errno == EPIPE)
        kill_thread( thread, 0 );  /* normal death */
    else
        fatal_protocol_perror( thread, "write" );
    return -1;
}

This just writes a command presumably to a pipe, how is this going to then 
result in a call to ptrace(PTRACE_CONT ...)

If a thread is stopped at the unix level, should not the wineserver restart 
the thread at the unix level before this is written ?