Date: Sun, 10 Oct 1999 13:33:57 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp-workers AT delorie DOT com cc: Charles Sandmann Subject: Debugging programs with SIGALRM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com 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 #include #include #include #include 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); }