From:	pavenis AT lanet DOT lv
Message-ID:	<B0000104814@stargate.astr.lu.lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com,
	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Date:	Tue, 12 Oct 1999 12:03:03 +0300
MIME-Version:	1.0
Subject:	Re: Debugging programs with SIGALRM
In-reply-to:	<Pine.SUN.3.91.991010133152.19886P-100000@is>
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

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

- Raw text -