+++ This bug was initially created as a clone of Bug #579622 +++ abrt 1.0.8 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: bash -c '$((2 ** 63 / -1))' comment: I saw this case mentioned in the sigaction(2) man page and wondered how bash handled it. component: bash executable: /bin/bash kernel: 2.6.32.10-90.fc12.x86_64 package: bash-4.0.35-2.fc12 rating: 4 reason: Process /bin/bash was killed by signal 8 (SIGFPE) release: Fedora release 12 (Constantine) How to reproduce: 1. bash -c '$((2 ** 63 / -1))' --- Additional comment from matt on 2010-04-06 00:58:20 EDT --- Created an attachment (id=404601) File: backtrace --- Additional comment from matt on 2010-04-06 01:01:32 EDT --- Bash specifically traps division by zero. If 2 ** 63 / -1 can result in a SIGFPE, bash should trap that too. (I'll admit it's unlikely that anyone will ever hit this in practice.) --- Additional comment from rrakus on 2010-04-06 07:16:39 EDT --- Thanks for the report. I will ask upstream what he thinks about it. --- Additional comment from matt on 2010-04-06 10:38:51 EDT --- This case is so easy to forget that it might be worth having a gnulib module for "division of untrusted integers without incurring SIGFPE".
Created attachment 404734 [details] Reproducer This is small reproducer. On 64 bit system the sequence `a/-c' will cause the SIGFPE, what is OK. But on 32 bit system the result is `-a'. The same like a/c. This is strange...
Overflow invokes undefined behaviour.
But, shouldn't be there also SIGFPE on 32bit system?
It's undefined.