14 Jul
2005
14 Jul
'05
1:17 p.m.
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
14 Jul
14 Jul
4:44 p.m.
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
--
Eric Pouech
16 Jul
16 Jul
3:08 a.m.
On Friday 15 July 2005 02:44, Eric Pouech wrote:
Robert Lunnon a écrit :
Nothing, the client doesn't get restarted it is in state "stop" when I look
at
the process with ps
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)
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
23 Jul
23 Jul
10:16 a.m.
On Friday 15 July 2005 02:44, Eric Pouech wrote:
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
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 ?
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 
4 Sep
4 Sep
7:54 a.m.
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+
--
Eric Pouech
6818
days inactive
6870
days old
4 comments
3 participants
participants (3)
-
Eric Pouech -
Eric Pouech -
Robert Lunnon