From: pavenis AT lanet DOT lv Message-ID: To: Eli Zaretskii , djgpp-workers AT delorie DOT com, Charles Sandmann Date: Tue, 12 Oct 1999 12:03:03 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Debugging programs with SIGALRM In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12a) Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 10 Oct 99, at 13:33, Eli Zaretskii wrote: > > 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? > I didn't test SIGALRM earlier but it looked rather evident we can expect problems there. Another possible way to run into trouble with dbgcom.c: redefine in debugee key that is translated to SIGINT and try to use it. I'm afraid we'll get something similar (however I also haven't tested it) Andris