X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Date: Thu, 10 Jan 2002 18:48:08 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: roland_asmann AT yahoo DOT com
Message-Id: <5567-Thu10Jan2002184807+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <20020110162441.98731.qmail@web9106.mail.yahoo.com> (message from
	ROLAND on Thu, 10 Jan 2002 08:24:41 -0800 (PST))
Subject: Re: Problem with alarm & signal
References:  <20020110162441 DOT 98731 DOT qmail AT web9106 DOT mail DOT yahoo DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 10 Jan 2002 08:24:41 -0800 (PST)
> From: ROLAND <roland_asmann AT yahoo DOT com>
> > 
> > and then type "disassmble 0x0f00115e", and see
> > whether GDB finds that
> > address in the program?
> 
> I did that, and GDB said something like:
> No function at specified address

This means what I suspected: that address is not inside your program,
it's somewhere else.

> BTW, Do I need to put the PMCOM source in this dir as
> well? I just put in the .a file, but maybe it needs
> the sources as well...

No, the disassembly command doesn't need the sources.

> I tried something different now, I first opened the
> program in GDB and typed run, and then the program
> crashed.
> Now I set a breakpoint, and run again, and then used
> step from the breakpoint on. At that point everything
> seemed to go allright. After having used step for a
> number of times (I was in a while-loop) I decided to
> let the program continue, so it maybe ran into the bug
> somewhere. The strangest thing then was, that the
> program didn't crash!

Running a program under a debugger changes many things, in particular
how hardware interrupts are processed.  So it's quite possible that
such bugs will behave differently under a debugger.

I think your best bet would be to read the sources of PMCOM and look
for code that uses DS, or accesses global variables without the CS:
override.  Such code is prone to break when the foreground code uses
signals (like you do with SIGALRM).