[Patch] x % 0 hangs

[Patch] x % 0 hangs

[David Lecomber]

Hi

On my x86, gdb does not enjoy evaluating x % 0 or x / 0 for any x: it
hangs.

Although there may be some systems that can healthily respond to this, I
propose a trivial patch - unless someone is going to tell me there's an
option to stop the hanging, or respond differently to the signal.

2004-06-26    <david@streamline-computing.com>

	* valarith.c: check for zero in division and remainder
	evaluation.

Index: valarith.c
===================================================================
RCS file: /cvs/src/src/gdb/valarith.c,v
retrieving revision 1.22
diff -u -p -r1.22 valarith.c
--- valarith.c  1 Apr 2004 12:08:30 -0000       1.22
+++ valarith.c  26 Jun 2004 09:21:31 -0000
@@ -1040,7 +1040,10 @@ value_binop (struct value *arg1, struct
              break;
  
            case BINOP_DIV:
-             v = v1 / v2;
+             if (v2 != 0)
+               v = v1 / v2;
+             else
+               error ("Cannot perform division: division by zero");
               break;
  
             case BINOP_EXP:
@@ -1050,7 +1053,10 @@ value_binop (struct value *arg1, struct
              break;
  
            case BINOP_REM:
-             v = v1 % v2;
+             if (v2 != 0)
+               v = v1 % v2;
+             else
+               error ("Cannot perform remainer: division by zero");
              break;
  
            case BINOP_MOD:

Re: [Patch] x % 0 hangs

[Michael Elizabeth Chastain]

I like your patch, although I can't approve it.

There is a PR for this:

  http://sources.redhat.com/gdb/bugs/1056
  divide by zero hangs gdb

Could you a line to your ChangeLog like this:

2004-06-26    <david@streamline-computing.com>

	Partial fix for PR cli/1056.
	* valarith.c: check for zero in division and remainder
	evaluation.

> Although there may be some systems that can healthily respond to this, I
> propose a trivial patch - unless someone is going to tell me there's an
> option to stop the hanging, or respond differently to the signal.

Someone still has to dive into the signal handling design and fix the
lower-level problem, which is analyzed in the PR.  Briefly, the problem
is that gdb defers the its response to the signal and returns from the
signal handler, but returning from the signal handler for SIGFPE can
re-execute the same instruction that hung.

But I'm all for patching value_binop and providing a friendly
error message for BINOP_DIV and BINOP_REM.  That's the most common
place a gdb user would generate a SIGFPE.

Michael C

Re: [Patch] x % 0 hangs

[Mark Kettenis]

   Date: Sat, 26 Jun 2004 11:44:20 -0400 (EDT)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   I like your patch, although I can't approve it.

   There is a PR for this:

     http://sources.redhat.com/gdb/bugs/1056
     divide by zero hangs gdb

   Could you a line to your ChangeLog like this:

   2004-06-26    <david@streamline-computing.com>

	   Partial fix for PR cli/1056.
	   * valarith.c: check for zero in division and remainder
	   evaluation.

   > Although there may be some systems that can healthily respond to this, I
   > propose a trivial patch - unless someone is going to tell me there's an
   > option to stop the hanging, or respond differently to the signal.

   Someone still has to dive into the signal handling design and fix the
   lower-level problem, which is analyzed in the PR.  Briefly, the problem
   is that gdb defers the its response to the signal and returns from the
   signal handler, but returning from the signal handler for SIGFPE can
   re-execute the same instruction that hung.

Fixing this is highly non-trivial.  The only approach that's somewhat
portable is longjmp-ing out of the signal handler, and even that seems
to have its problems on some platforms.  Therefore I think this patch
is a very good idea.

I just wonder whether just printing "Division by zero" as the error
message would be enough.

David, consider this patch with or without that change approved.
Please modify your ChangeLog as requested by Michael though.

Mark

Re: [Patch] x % 0 hangs

[Andrew Cagney]

> The only approach that's somewhat
> portable is longjmp-ing out of the signal handler, and even that seems
> to have its problems on some platforms.

I'm curious, which platforms?

Re: [Patch] x % 0 hangs

[Ian Lance Taylor]

Andrew Cagney <cagney@gnu.org> writes:

> > The only approach that's somewhat
> > portable is longjmp-ing out of the signal handler, and even that seems
> > to have its problems on some platforms.
> 
> I'm curious, which platforms?

I would think that it would be safe enough to longjmp on SIGFPE into
the gdb catch_errors stack.  You would obviously be in trouble if the
SIGFPE came from any libc stdio routine, but I would expect that to be
impossible with a working library.

Ian

Re: [Patch] x % 0 hangs

[Mark Kettenis]

   From: Ian Lance Taylor <ian@wasabisystems.com>
   Date: 27 Jun 2004 11:06:19 -0400

   Andrew Cagney <cagney@gnu.org> writes:

   > > The only approach that's somewhat
   > > portable is longjmp-ing out of the signal handler, and even that seems
   > > to have its problems on some platforms.
   > 
   > I'm curious, which platforms?

Over the years I've seen quite a few bug-reports about this failing to
work, but I can't remember exectly which platforms were affected.  It
may be related to what I say in the next paragraph though.

Anyway, if/when we start longjmp-ing out of signal handlers we have to
realize the we must restore the proper signal mask (not all
sigjmp/longjmp implementations do that) and perhaps re-install the
SIGFPE signal handler.

   I would think that it would be safe enough to longjmp on SIGFPE into
   the gdb catch_errors stack.  You would obviously be in trouble if the
   SIGFPE came from any libc stdio routine, but I would expect that to be
   impossible with a working library.

The worst case is that we'll crash, which still is an improvement over
just hanging like we do now on some platforms :-).

Mark

Re: [Patch] x % 0 hangs

[Andrew Cagney]

>    From: Ian Lance Taylor <ian@wasabisystems.com>
>    Date: 27 Jun 2004 11:06:19 -0400
> 
>    Andrew Cagney <cagney@gnu.org> writes:
> 
>    > > The only approach that's somewhat
>    > > portable is longjmp-ing out of the signal handler, and even that seems
>    > > to have its problems on some platforms.
>    > 
>    > I'm curious, which platforms?
> 
> Over the years I've seen quite a few bug-reports about this failing to
> work, but I can't remember exectly which platforms were affected.

We need start with a working assumption that GDB is being run on POSIX 
compliant systems and that implies a working sigsetjmp / siglongjmp. 
Only when someone comes forward with a problematic system should we 
worry about it (and possibly not even then).

(BTW, the other way to handle this is to implement a s/w emulation of 
the inferior's arithmetic, that would never throw a SIGFPE).

Andrew

Re: [Patch] x % 0 hangs

[Mark Kettenis]

   Date: Mon, 28 Jun 2004 10:25:26 -0400
   From: Andrew Cagney <cagney@gnu.org>

   We need start with a working assumption that GDB is being run on POSIX 
   compliant systems and that implies a working sigsetjmp / siglongjmp. 
   Only when someone comes forward with a problematic system should we 
   worry about it (and possibly not even then).

Sorry, but I don't think fully POSIX compliant systems do actually
exist.  We should aim to have a working GDB on as many systems that
are in somewhat wide use as possible.  At the very minimum we should
support the latest official release of the GNU systems and other major
Free OS'es out there.

   (BTW, the other way to handle this is to implement a s/w emulation of 
   the inferior's arithmetic, that would never throw a SIGFPE).

Yes!

Mark

Re: [Patch] x % 0 hangs

[Andrew Cagney]

(cleaning up old threads)

>    Date: Mon, 28 Jun 2004 10:25:26 -0400
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    We need start with a working assumption that GDB is being run on POSIX 
>    compliant systems and that implies a working sigsetjmp / siglongjmp. 
>    Only when someone comes forward with a problematic system should we 
>    worry about it (and possibly not even then).
> 
> Sorry, but I don't think fully POSIX compliant systems do actually
> exist.  We should aim to have a working GDB on as many systems that
> are in somewhat wide use as possible.  At the very minimum we should
> support the latest official release of the GNU systems and other major
> Free OS'es out there.

For such systems lets at least assume that they more or less work, at 
least until our testsuite reveals evidence to the contrary.

Andrew