Mail Archives: djgpp-workers/1999/10/10/08:01:55
Did anyone try to debug a program that uses timers or alarm()?
The simple test program below crashes inside GDB after a couple of
alarms. The simple patch to dbgcom.c, also attached below, fixes
that.
After applying the patch, the program runs fine inside GDB, as long as
you don't try to stop it. But if you do stop it, either by putting a
breakpoint inside the SIGALRM handler, or with "handle SIGALRM print",
it behaves erratically, e.g., the printf lines seem to be invoked
twice (what? how??), and eventually crashes.
Does someone have any idea what might be the reason? It seems like
some window of opportunity is opened when the thread jumps between the
debugger and the debuggee, whereby if the exception generated by the
timer handler happens inside that window, it causes bad things. I'm
almost sure I see ESP and EBP that don't belong to each other in the
registers' dump when the debuggee crashes.
Is it possible that this is because longjmp doesn't disable interrupts
when it fiddles with SS:ESP? Should we CLI there?
------------------------------------------------------------------
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <conio.h>
#include <dpmi.h>
void alarm_handler (int sig)
{
printf ("\nALARM 1!!\n");
printf ("ALARM 2!!\n");
alarm (2);
}
int main (void)
{
signal (SIGALRM, alarm_handler);
alarm (3);
while (!kbhit ())
{
printf ("Idling...\r");
__dpmi_yield ();
}
return 0;
}
--------------------------------------------------------------------------
--- src/debug/common/dbgcom.c~1 Tue Sep 21 21:54:56 1999
+++ src/debug/common/dbgcom.c Sat Oct 9 16:40:46 1999
@@ -1086,7 +1086,6 @@ static void call_app_exception(int signu
cur_pos[5] = eflags;
cur_pos[6] = esp;
cur_pos[7] = ss;
- cur_pos += 8;
longjmp(load_state, load_state->__eax);
}
- Raw text -