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))'
Created attachment 404601 [details] File: backtrace
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.)
Thanks for the report. I will ask upstream what he thinks about it.
This case is so easy to forget that it might be worth having a gnulib module for "division of untrusted integers without incurring SIGFPE".
You can track the discussion on bash bug mailing list; http://www.mail-archive.com/bug-bash@gnu.org/msg07182.html Chet is not convinced of the need. I think you can easily use trap to catch it.
It's not really possible to "catch" the SIGFPE with trap. When the trap handler returns, the faulting division will be performed again and the trap handler will be called again. There is no way to resume normal execution after the division.
Ah, yes. You're right.
There will not be any change here as discussed upstream.
WONTFIX is a more accurate description of the decision made.
The upstream discussion: http://lists.gnu.org/archive/html/bug-bash/2010-04/msg00020.html
*** Bug 594473 has been marked as a duplicate of this bug. ***