SIGFPE crash

SIGFPE crash

[Jon Mayo]

echo $[-9223372036854775808/-1]

this causes zsh to exit immediately with an FPE. Does anyone have a
patch to fix this?

- Jon

Re: SIGFPE crash

[Mikael Magnusson]

On 7 May 2011 23:56, Jon Mayo <jon.mayo@gmail.com> wrote:
> echo $[-9223372036854775808/-1]
>
> this causes zsh to exit immediately with an FPE. Does anyone have a
> patch to fix this?

diff --git a/Src/math.c b/Src/math.c
index 35b362d..3c08052 100644
--- a/Src/math.c
+++ b/Src/math.c
@@ -1053,8 +1053,12 @@ op(int what)
                    return;
                if (c.type == MN_FLOAT)
                    c.u.d = a.u.d / b.u.d;
-               else
-                   c.u.l = a.u.l / b.u.l;
+               else {
+                    if (a.u.l == LONG_MIN && b.u.l == -1)
+                        c.u.l = 0;
+                    else
+                       c.u.l = a.u.l / b.u.l;
+                }
                break;
            case MOD:
            case MODEQ:


Do we want to print a warning and/or use another value than 0 in this case?

-- 
Mikael Magnusson

Re: SIGFPE crash

[Jon Mayo]

On Sat, May 7, 2011 at 3:17 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 7 May 2011 23:56, Jon Mayo <jon.mayo@gmail.com> wrote:
>> echo $[-9223372036854775808/-1]
>>
>> this causes zsh to exit immediately with an FPE. Does anyone have a
>> patch to fix this?
>
> diff --git a/Src/math.c b/Src/math.c
> index 35b362d..3c08052 100644
> --- a/Src/math.c
> +++ b/Src/math.c
> @@ -1053,8 +1053,12 @@ op(int what)
>                    return;
>                if (c.type == MN_FLOAT)
>                    c.u.d = a.u.d / b.u.d;
> -               else
> -                   c.u.l = a.u.l / b.u.l;
> +               else {
> +                    if (a.u.l == LONG_MIN && b.u.l == -1)

should be LLONG_MIN

> +                        c.u.l = 0;

LLONG_MAX would be the closest answer, but 1 off. I would switch it
from integer to double type in this case, but that might be difficult.

> +                    else
> +                       c.u.l = a.u.l / b.u.l;
> +                }
>                break;
>            case MOD:
>            case MODEQ:
>
>
> Do we want to print a warning and/or use another value than 0 in this case?
>
> --
> Mikael Magnusson
>

-- Jon

Re: SIGFPE crash

[Mikael Magnusson]

On 8 May 2011 00:19, Jon Mayo <jon.mayo@gmail.com> wrote:
> On Sat, May 7, 2011 at 3:17 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
>> On 7 May 2011 23:56, Jon Mayo <jon.mayo@gmail.com> wrote:
>>> echo $[-9223372036854775808/-1]
>>>
>>> this causes zsh to exit immediately with an FPE. Does anyone have a
>>> patch to fix this?
>>
>> diff --git a/Src/math.c b/Src/math.c
>> index 35b362d..3c08052 100644
>> --- a/Src/math.c
>> +++ b/Src/math.c
>> @@ -1053,8 +1053,12 @@ op(int what)
>>                    return;
>>                if (c.type == MN_FLOAT)
>>                    c.u.d = a.u.d / b.u.d;
>> -               else
>> -                   c.u.l = a.u.l / b.u.l;
>> +               else {
>> +                    if (a.u.l == LONG_MIN && b.u.l == -1)
>
> should be LLONG_MIN
>
>> +                        c.u.l = 0;
>
> LLONG_MAX would be the closest answer, but 1 off. I would switch it
> from integer to double type in this case, but that might be difficult.

It should probably be neither, zsh does some weird stuff to find a
suitably long type for .l, which may or may not be a long long.

>> +                    else
>> +                       c.u.l = a.u.l / b.u.l;
>> +                }
>>                break;
>>            case MOD:
>>            case MODEQ:
>>
>>
>> Do we want to print a warning and/or use another value than 0 in this case?

This is assuming we want to do this at all, I am told that only
division will generate an exception on x86, but presumably other
arches behave differently, and bash behaves the same way too
(exception + die). Does some sort of standard have anything to say on
the matter? I'm guessing someone has thought of it before and clearly
nobody ever did anything about it.

-- 
Mikael Magnusson

Re: SIGFPE crash

[Phil Pennock]

On 2011-05-08 at 00:27 +0200, Mikael Magnusson wrote:
[ mod/modeq ]
> This is assuming we want to do this at all, I am told that only
> division will generate an exception on x86, but presumably other
> arches behave differently, and bash behaves the same way too
> (exception + die). Does some sort of standard have anything to say on
> the matter? I'm guessing someone has thought of it before and clearly
> nobody ever did anything about it.

At least in the INT_MIN case for integers, modulo arithmetic generates
this exception.

I checked, Exim has the same issue, http://bugs.exim.org/1112 filed,
referencing this thread.  From that:

% exim -be
> ${eval:-2147483648%-1}
zsh: floating point exception  exim -be

*sigh*

-Phil

Re: SIGFPE crash

[Jon Mayo]

On Sat, May 7, 2011 at 3:27 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 8 May 2011 00:19, Jon Mayo <jon.mayo@gmail.com> wrote:
>> On Sat, May 7, 2011 at 3:17 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
>>> On 7 May 2011 23:56, Jon Mayo <jon.mayo@gmail.com> wrote:
>>>> echo $[-9223372036854775808/-1]
>>>>
>>>> this causes zsh to exit immediately with an FPE. Does anyone have a
>>>> patch to fix this?
>>>
>>> diff --git a/Src/math.c b/Src/math.c
>>> index 35b362d..3c08052 100644
>>> --- a/Src/math.c
>>> +++ b/Src/math.c
>>> @@ -1053,8 +1053,12 @@ op(int what)
>>>                    return;
>>>                if (c.type == MN_FLOAT)
>>>                    c.u.d = a.u.d / b.u.d;
>>> -               else
>>> -                   c.u.l = a.u.l / b.u.l;
>>> +               else {
>>> +                    if (a.u.l == LONG_MIN && b.u.l == -1)
>>
>> should be LLONG_MIN
>>
>>> +                        c.u.l = 0;
>>
>> LLONG_MAX would be the closest answer, but 1 off. I would switch it
>> from integer to double type in this case, but that might be difficult.
>
> It should probably be neither, zsh does some weird stuff to find a
> suitably long type for .l, which may or may not be a long long.
>
>>> +                    else
>>> +                       c.u.l = a.u.l / b.u.l;
>>> +                }
>>>                break;
>>>            case MOD:
>>>            case MODEQ:
>>>
>>>
>>> Do we want to print a warning and/or use another value than 0 in this case?
>
> This is assuming we want to do this at all, I am told that only
> division will generate an exception on x86, but presumably other
> arches behave differently, and bash behaves the same way too
> (exception + die). Does some sort of standard have anything to say on
> the matter? I'm guessing someone has thought of it before and clearly
> nobody ever did anything about it.
>

perhaps scripts that care can just use a trap? and all my worrying was
for nothing?
mostly I ran into the issue while I dropped out of vi to do some
calculations, and ended up having zsh crash and had to recover my
editing session. minor annoyance really.

Re: SIGFPE crash

[Mikael Magnusson]

On 8 May 2011 02:05, Jon Mayo <jon.mayo@gmail.com> wrote:
> On Sat, May 7, 2011 at 3:27 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
>> This is assuming we want to do this at all, I am told that only
>> division will generate an exception on x86, but presumably other
>> arches behave differently, and bash behaves the same way too
>> (exception + die). Does some sort of standard have anything to say on
>> the matter? I'm guessing someone has thought of it before and clearly
>> nobody ever did anything about it.
>>
>
> perhaps scripts that care can just use a trap? and all my worrying was
> for nothing?
> mostly I ran into the issue while I dropped out of vi to do some
> calculations, and ended up having zsh crash and had to recover my
> editing session. minor annoyance really.

Using a trap doesn't seem to work, it just causes an infinite loop
running the instruction over and over again.
fwiw, bash behaves the same way, both with regards to crashing and
looping on the trap.

-- 
Mikael Magnusson

Re: SIGFPE crash

[Bart Schaefer]

On May 7,  2:56pm, Jon Mayo wrote:
}
} echo $[-9223372036854775808/-1]
} 
} this causes zsh to exit immediately with an FPE. Does anyone have a
} patch to fix this?

Interesting.

schaefer<505> echo $[-9223372036854775808/-1]  
-9223372036854775808
schaefer<506> echo $[-9223372036854775809/-1]
zsh: number truncated after 18 digits: 9223372036854775809/-1
922337203685477580

No FPE in either case.

On May 7,  5:05pm, Jon Mayo wrote:
}
} perhaps scripts that care can just use a trap? and all my worrying was
} for nothing?

I'm having a hard time testing this because I can't get a mathematically
induced FPE, but recall that (quoting the doc):

   * The return status from function traps is special, whereas a return
     from a list trap causes the surrounding context to return with the
     given status.

So if you use

    trap 'return 1' FPE

you might avoid the infinite retry of the operation that Mikael reported.

-- 

Re: SIGFPE crash

[Jon Mayo]

On Sat, May 7, 2011 at 7:46 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 7,  2:56pm, Jon Mayo wrote:
> }
> } echo $[-9223372036854775808/-1]
> }
> } this causes zsh to exit immediately with an FPE. Does anyone have a
> } patch to fix this?
>
> Interesting.
>
> schaefer<505> echo $[-9223372036854775808/-1]
> -9223372036854775808
> schaefer<506> echo $[-9223372036854775809/-1]
> zsh: number truncated after 18 digits: 9223372036854775809/-1
> 922337203685477580
>
> No FPE in either case.
>
> On May 7,  5:05pm, Jon Mayo wrote:
> }
> } perhaps scripts that care can just use a trap? and all my worrying was
> } for nothing?
>
> I'm having a hard time testing this because I can't get a mathematically
> induced FPE, but recall that (quoting the doc):
>
>   * The return status from function traps is special, whereas a return
>     from a list trap causes the surrounding context to return with the
>     given status.
>
> So if you use
>
>    trap 'return 1' FPE
>
> you might avoid the infinite retry of the operation that Mikael reported.
>
> --
>

nope, it spins with 100% cpu even on that one.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2790 jon       20   0 40740 3292 1896 R  100  0.0   0:17.17 zsh

- Jon

Re: SIGFPE crash

[Peter Stephenson]

On Sun, 8 May 2011 00:27:30 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> >> +                    if (a.u.l == LONG_MIN && b.u.l == -1)
> >
> > should be LLONG_MIN
> >
> 
> It should probably be neither, zsh does some weird stuff to find a
> suitably long type for .l, which may or may not be a long long.

It needs a test in configure.ac where we check the type, around line
967, to check if LLONG_MIN and LLONG_MAX exist and if so define
ZSH_INT_MIN and ZSH_INT_MAX to those, and a bit later (after
the 64 bit stuff) if we didn't define them yet, test for LONG_MIN and
LONG_MAX and use those, otherwise (which shouldn't really happen) just
use some hackery with sizeof and shifts as a fallback (and perhaps print
a warning that we'd like to know about it).

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: SIGFPE crash

[Vincent Lefevre]

On 2011-05-08 00:27:30 +0200, Mikael Magnusson wrote:
> This is assuming we want to do this at all,

One should have a well-defined behavior.

> I am told that only division will generate an exception on x86, but
> presumably other arches behave differently,

Perhaps, but this also depends on the compiler. The operation
LONG_MIN/(-1) has an undefined behavior in two's complement
because the result is not representable. So, it should be avoided.

> and bash behaves the same way too (exception + die). Does some sort
> of standard have anything to say on the matter? I'm guessing someone
> has thought of it before and clearly nobody ever did anything about
> it.

It seems that POSIX just says:

  If the expression is invalid, the expansion fails and the shell
  shall write a message to standard error indicating the failure.

The behavior doesn't seem to be explicitly specified when there is
an overflow, and may be covered by an extension to provide a valid
result (e.g. using floating-point). Otherwise I suppose that the
behavior should not be worse than an invalid expression, e.g. a
crash shouldn't occur.

At least zsh should behave in a consistent way. For instance,
$((0/0)) returns an error, so that it should be the same case
with the minimum integer divided by -1.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: SIGFPE crash

[Vincent Lefevre]

On 2011-05-07 15:19:43 -0700, Jon Mayo wrote:
> On Sat, May 7, 2011 at 3:17 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> > On 7 May 2011 23:56, Jon Mayo <jon.mayo@gmail.com> wrote:
> >> echo $[-9223372036854775808/-1]
> >>
> >> this causes zsh to exit immediately with an FPE. Does anyone have a
> >> patch to fix this?
> >
> > diff --git a/Src/math.c b/Src/math.c
> > index 35b362d..3c08052 100644
> > --- a/Src/math.c
> > +++ b/Src/math.c
> > @@ -1053,8 +1053,12 @@ op(int what)
> >                    return;
> >                if (c.type == MN_FLOAT)
> >                    c.u.d = a.u.d / b.u.d;
> > -               else
> > -                   c.u.l = a.u.l / b.u.l;
> > +               else {
> > +                    if (a.u.l == LONG_MIN && b.u.l == -1)
> 
> should be LLONG_MIN
> 
> > +                        c.u.l = 0;
> 
> LLONG_MAX would be the closest answer, but 1 off.

I think this would be very bad. "closest answer" makes sense in
floating-point arithmetic, but on the integers, one can have a
different metric, and zsh doesn't know the choice of the user.

> I would switch it from integer to double type in this case, but that
> might be difficult.

This wouldn't be consistent with the other cases of error, such
as overflows:

$ echo $((-9223372036854775808-1))
9223372036854775807

(the switch to floating-point would have given a different result,
which would be negative) or divisions by 0:

$ echo $((0/0))
zsh: division by zero

with exit status 1, instead of NaN.

IMHO, the best behavior would be an error "division overflow" with
exit status 1.

Note: the modular arithmetic can make sense with addition, subtraction
and multiplication (though an error may be safer), but not with the
division, so that returning LLONG_MIN would not be a good idea, IMHO.
Also, I haven't looked at the zsh code, but if zsh obtains modular
arithmetic by a side effect of the behavior of the processor, then
this is wrong: overflow on signed integer types is undefined behavior
in C (with GCC, you need the -fwrapv option if you want to support
modular arithmetic on signed integer types, otherwise one doesn't know
what optimizations will do).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)