More debugger quesions

[Robert Lunnon]

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 ?

All help appreciated

Bob

[Eric Pouech]

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

[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)

Nothing, the client doesn't get restarted it is in state "stop" when I look at 
the process with ps
> - 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)

OK, this seams a good place to look

Sorry about the continual questions... I'm well out of my comfort zone on this 
project.

Bob
> HTH

[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 ?

[Eric Pouech]

Robert Lunnon a écrit :
> 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

basically what happens:
let's call P the process that sends the debug event (ie the process being 
debugger) and D the debugger

- P gets an exception, and first wants to notify the debugger
- P calls queue_exception_event in wineserver
- WS (wineserver) then suspends P (ie signals every thread of P with SIGUSR1)
- WS queues debug event
- D gets the event (wait_debug_event)
- D handles the event
- D informs WS it's done with the event (continue_debug_event)
- WS then resumes every thread of P (that's the wakeup_thread function)
- P (in fact the thread that queued the event) resumes and can fetch the result 
of the handling of the debug event

HTH
A+