Bug 579808

Summary: Strange behaviour of intmax_t variables
Product: [Fedora] Fedora Reporter: Roman Rakus <rrakus>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fweimer, jakub, matt, rrakus, schwab, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: abrt_hash:fed561a6216f6b7f596b077f7e7821ffc2f5dc12
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 579622 Environment:
Last Closed: 2010-04-06 16:04:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Reproducer none

Description Roman Rakus 2010-04-06 15:48:18 UTC
+++ 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".

Comment 1 Roman Rakus 2010-04-06 15:51:54 UTC
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...

Comment 2 Andreas Schwab 2010-04-06 16:04:19 UTC
Overflow invokes undefined behaviour.

Comment 3 Roman Rakus 2010-04-06 16:11:37 UTC
But, shouldn't be there also SIGFPE on 32bit system?

Comment 4 Matt McCutchen 2010-04-06 18:03:52 UTC
It's undefined.