Can arithmetic evaluation trap more than just division by zero?
Is it possible to add more traps to arithmetic evaluation? Repeated by: $((2 ** 63 / -1)) Actual result: SIGFPE (not catched) Initial report is https://bugzilla.redhat.com/show_bug.cgi?id=579622 RR
Re: Can arithmetic evaluation trap more than just division by zero?
On Tue, Apr 06, 2010 at 01:29:28PM +0200, Roman Rakus wrote: > Is it possible to add more traps to arithmetic evaluation? > Repeated by: > $((2 ** 63 / -1)) > > Actual result: > SIGFPE (not catched) > > Initial report is https://bugzilla.redhat.com/show_bug.cgi?id=579622 Hmm, I don't get that. imadev:~$ uname -sr; echo $BASH_VERSION HP-UX B.10.20 4.1.2(2)-release imadev:~$ echo $((2 ** 63 / -1)) -9223372036854775808 arc3:~$ uname -sr; echo $BASH_VERSION Linux 2.6.26-2-686 3.2.39(1)-release arc3:~$ echo $((2 ** 63 / -1)) -9223372036854775808
Re: Can arithmetic evaluation trap more than just division by zero?
On 04/06/2010 01:49 PM, Greg Wooledge wrote: On Tue, Apr 06, 2010 at 01:29:28PM +0200, Roman Rakus wrote: Is it possible to add more traps to arithmetic evaluation? Repeated by: $((2 ** 63 / -1)) Actual result: SIGFPE (not catched) Initial report is https://bugzilla.redhat.com/show_bug.cgi?id=579622 Hmm, I don't get that. imadev:~$ uname -sr; echo $BASH_VERSION HP-UX B.10.20 4.1.2(2)-release imadev:~$ echo $((2 ** 63 / -1)) -9223372036854775808 arc3:~$ uname -sr; echo $BASH_VERSION Linux 2.6.26-2-686 3.2.39(1)-release arc3:~$ echo $((2 ** 63 / -1)) -9223372036854775808 I can reproduce it in 4.1.2(1)-release and 4.0.23(1)-release on x86_64 GNU/Linux. I didn't try on bash 3.2. RR
Re: Can arithmetic evaluation trap more than just division by zero?
On Tue, Apr 06, 2010 at 02:21:05PM +0200, Roman Rakus wrote: > >>$((2 ** 63 / -1)) > I can reproduce it in 4.1.2(1)-release and 4.0.23(1)-release on x86_64 > GNU/Linux. I didn't try on bash 3.2. cyclops:~$ uname -a; echo $BASH_VERSION OpenBSD cyclops.wooledge.org 4.6 GENERIC.MP#81 amd64 4.0.24(1)-release cyclops:~$ echo $((2 ** 63 / -1)) Connection to cyclops closed. griffon:~$ An amd64-specific bug, then? (The Linux box I tested on earlier is i386, and the HP-UX box is PA-RISC 2.0.)
Bash-4.1 Official Patch 3
BASH PATCH REPORT
=
Bash-Release: 4.1
Patch-ID: bash41-003
Bug-Reported-by:coy...@wariat.org.pl
Bug-Reference-ID: <4b64a1f8.06e2660a.60af.4...@mx.google.com>
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2010-01/msg00135.html
Bug-Description:
If command completion is attempted on a word with a quoted globbing
character (e.g., `*' or `?'), bash can reference a NULL pointer and
dump core.
Patch (apply with `patch -p0'):
*** ../bash-4.1-patched/bashline.c 2009-10-24 14:10:19.0 -0400
--- bashline.c 2010-01-30 21:53:49.0 -0500
***
*** 1681,1685
characters in the common prefix are bad) will ever be returned on
regular completion. */
! if (glob_pattern_p (hint))
{
if (state == 0)
--- 1681,1685
characters in the common prefix are bad) will ever be returned on
regular completion. */
! if (globpat)
{
if (state == 0)
*** ../bash-4.1-patched/patchlevel.h2009-10-01 16:39:22.0 -0400
--- patchlevel.h2010-01-14 09:38:08.0 -0500
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 2
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 3
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.1 Official Patch 4
BASH PATCH REPORT
=
Bash-Release: 4.1
Patch-ID: bash41-004
Bug-Reported-by:Crestez Dan Leonard
Bug-Reference-ID: <1265592839.30682.21.ca...@deskbox>
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2010-02/msg00034.html
Bug-Description:
When running in Posix mode and executing a shell function without local
variables, bash will not propagate a variable in a special builtin's temporary
environment to have global scope.
Patch (apply with `patch -p0'):
*** ../bash-4.1-patched/variables.c 2009-11-03 14:13:58.0 -0500
--- variables.c 2010-02-08 17:36:18.0 -0500
***
*** 3809,3812
--- 3809,3817
if (tempvar_p (var) && (posixly_correct || (var->attributes &
att_propagate)))
{
+ /* Make sure we have a hash table to store the variable in while it is
+being propagated down to the global variables table. Create one if
+we have to */
+ if ((vc_isfuncenv (shell_variables) || vc_istempenv (shell_variables))
&& shell_variables->table == 0)
+ shell_variables->table = hash_create (0);
/* XXX - should we set v->context here? */
v = bind_variable_internal (var->name, value_cell (var),
shell_variables->table, 0, 0);
*** ../bash-4.1-patched/patchlevel.h2009-10-01 16:39:22.0 -0400
--- patchlevel.h2010-01-14 09:38:08.0 -0500
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 3
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 4
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.1 Official Patch 5
BASH PATCH REPORT
=
Bash-Release: 4.1
Patch-ID: bash41-005
Bug-Reported-by:wer...@suse.de
Bug-Reference-ID: <201002251238.o1pccycg016...@boole.suse.de>
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2010-02/msg00132.html
Bug-Description:
When the `read' builtin times out after the timeout specified with -t is
exceeded, it does not reset the flags that tell signal handlers to process
signals immediately instead of deferring their handling. This can result
in unsafe functions being called from signal handlers, which can cause bash
to hang or dump core.
Patch (apply with `patch -p0'):
*** ../bash-4.1-patched/builtins/read.def 2009-10-08 11:35:46.0
-0400
--- builtins/read.def 2010-03-17 17:35:39.0 -0400
***
*** 616,621
zsyncfd (fd);
- interrupt_immediately--;
- terminate_immediately--;
discard_unwind_frame ("read_builtin");
--- 616,619
***
*** 624,627
--- 622,628
assign_vars:
+ interrupt_immediately--;
+ terminate_immediately--;
+
#if defined (ARRAY_VARS)
/* If -a was given, take the string read, break it into a list of words,
*** ../bash-4.1-patched/patchlevel.h2009-10-01 16:39:22.0 -0400
--- patchlevel.h2010-01-14 09:38:08.0 -0500
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 4
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 5
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
On Tue, Apr 06, 2010 at 08:35:13AM -0400, Greg Wooledge wrote: > On Tue, Apr 06, 2010 at 02:21:05PM +0200, Roman Rakus wrote: > > >>$((2 ** 63 / -1)) > > > I can reproduce it in 4.1.2(1)-release and 4.0.23(1)-release on x86_64 > > GNU/Linux. I didn't try on bash 3.2. > > cyclops:~$ uname -a; echo $BASH_VERSION > OpenBSD cyclops.wooledge.org 4.6 GENERIC.MP#81 amd64 > 4.0.24(1)-release > cyclops:~$ echo $((2 ** 63 / -1)) > Connection to cyclops closed. > griffon:~$ > > An amd64-specific bug, then? (The Linux box I tested on earlier is i386, > and the HP-UX box is PA-RISC 2.0.) On x86_64 I see: ~> echo $((2 ** 63 / -1)) Floating exception whereas on i686 ~> echo $((2 ** 63 / -1)) -9223372036854775808 ... both GNU/Linux. On x86_64 the gdb shows: Program received signal SIGFPE, Arithmetic exception. 0x00462cd5 in exp2 () at expr.c:761 761 val1 /= val2; (gdb) print val1 $1 = -9223372036854775808 (gdb) print val2 $2 = -1 which is strange. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Re: Can arithmetic evaluation trap more than just division by zero?
On 04/06/2010 02:35 PM, Greg Wooledge wrote: On Tue, Apr 06, 2010 at 02:21:05PM +0200, Roman Rakus wrote: $((2 ** 63 / -1)) I can reproduce it in 4.1.2(1)-release and 4.0.23(1)-release on x86_64 GNU/Linux. I didn't try on bash 3.2. cyclops:~$ uname -a; echo $BASH_VERSION OpenBSD cyclops.wooledge.org 4.6 GENERIC.MP#81 amd64 4.0.24(1)-release cyclops:~$ echo $((2 ** 63 / -1)) Connection to cyclops closed. griffon:~$ An amd64-specific bug, then? (The Linux box I tested on earlier is i386, and the HP-UX box is PA-RISC 2.0.) I guess the bug is somewhere in glibc and specific for 32 bit systems. (2^63) is same as (2^63/-1) on 32bit system (tested on ppc32). RR
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
"Dr. Werner Fink" writes: > On x86_64 the gdb shows: > > Program received signal SIGFPE, Arithmetic exception. > 0x00462cd5 in exp2 () at expr.c:761 > 761 val1 /= val2; > (gdb) print val1 > $1 = -9223372036854775808 > (gdb) print val2 > $2 = -1 > > which is strange. Not at all. Overflow invokes undefined behaviour. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
On 04/06/2010 03:59 PM, Andreas Schwab wrote: "Dr. Werner Fink" writes: On x86_64 the gdb shows: Program received signal SIGFPE, Arithmetic exception. 0x00462cd5 in exp2 () at expr.c:761 761 val1 /= val2; (gdb) print val1 $1 = -9223372036854775808 (gdb) print val2 $2 = -1 which is strange. Not at all. Overflow invokes undefined behaviour. Andreas. But why there is no overflow on 32bit system? RR
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
Roman Rakus writes: > But why there is no overflow on 32bit system? Why do you think so? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
Program received signal SIGFPE, Arithmetic exception. 0x00462cd5 in exp2 () at expr.c:761 761 val1 /= val2; (gdb) print val1 $1 = -9223372036854775808 (gdb) print val2 $2 = -1 which is strange. Not at all. Overflow invokes undefined behaviour. But why there is no overflow on 32bit system? No *detected* overflow. For instance, if computing (2 ** 63) gives 0 (the low-order 32 bits of the true result) and does not detect the overflow (or ignores the overflow, either by intention or by bug), then there is no problem with computing (0 / -1). --
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
On 04/06/2010 05:32 PM, John Reiser wrote: Program received signal SIGFPE, Arithmetic exception. 0x00462cd5 in exp2 () at expr.c:761 761 val1 /= val2; (gdb) print val1 $1 = -9223372036854775808 (gdb) print val2 $2 = -1 which is strange. Not at all. Overflow invokes undefined behaviour. But why there is no overflow on 32bit system? No *detected* overflow. For instance, if computing (2 ** 63) gives 0 (the low-order 32 bits of the true result) and does not detect the overflow (or ignores the overflow, either by intention or by bug), then there is no problem with computing (0 / -1). Thanks for clarifying my words. So, on 32bit systems, evaluation of (2 ** 63 / -1) gives the wrong number. RR
Re: [bash-bug] Can arithmetic evaluation trap more than just division by zero?
On 4/6/10 11:56 AM, Roman Rakus wrote: > On 04/06/2010 05:32 PM, John Reiser wrote: > Program received signal SIGFPE, Arithmetic exception. > 0x00462cd5 in exp2 () at expr.c:761 > 761 val1 /= val2; > (gdb) print val1 > $1 = -9223372036854775808 > (gdb) print val2 > $2 = -1 > > which is strange. >> Not at all. Overflow invokes undefined behaviour. >> >>> But why there is no overflow on 32bit system? >> >> No *detected* overflow. For instance, if computing (2 ** 63) >> gives 0 (the low-order 32 bits of the true result) and >> does not detect the overflow (or ignores the overflow, >> either by intention or by bug), then there is no problem >> with computing (0 / -1). >> > Thanks for clarifying my words. > So, on 32bit systems, evaluation of (2 ** 63 / -1) gives the wrong number. It shouldn't matter whether or not the system is 32-bit. Bash performs arithmetic on intmax_t values, which are 64 bits on all Linux systems I have available, at least. I'm not sure whether the compiler or libc has greater responsibility for manipulating 64-bit quantities. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
