Bug#210981: marked as done (libc6: printf crashes on a certain long double)
Your message dated Mon, 15 Sep 2003 09:32:50 -0400
with message-id <20030915133250.GA13333@nevyn.them.org>
and subject line Bug#210981: libc6: printf crashes on a certain long double
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 15 Sep 2003 04:00:29 +0000
>From drow@crack.them.org Sun Sep 14 23:00:27 2003
Return-path: <drow@crack.them.org>
Received: from dsl093-172-017.pit1.dsl.speakeasy.net (nevyn.them.org) [66.93.172.17]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19ykXL-0003mp-00; Sun, 14 Sep 2003 23:00:27 -0500
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
id 19ykXL-0005cS-2p
for <submit@bugs.debian.org>; Mon, 15 Sep 2003 00:00:27 -0400
Date: Mon, 15 Sep 2003 00:00:27 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libc6: printf crashes on a certain long double
Message-ID: <[🔎] 20030915040027.GA20959@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Reportbug-Version: 2.28
User-Agent: Mutt/1.5.1i
Delivered-To: submit@bugs.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0
tests=HAS_PACKAGE
version=2.53-bugs.debian.org_2003_9_14
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_9_14 (1.174.2.15-2003-03-30-exp)
Package: libc6
Version: 2.3.2-7
Severity: normal
Try it:
int data[] = {0x00000000, 0x00000000, 0x00000cd0};
struct ieee {
unsigned int mantissa1:32;
unsigned int mantissa0:30;
unsigned int quiet_nan:1;
unsigned int one:1;
unsigned int exponent:15;
unsigned int negative:1;
unsigned int empty:16;
} *pieee = data;
long double *doub = (long double *) data;
int main()
{
char *ret = 0;
printf ("%.35Lg\n", *doub);
vasprintf (&ret, "%.35Lg", doub);
printf ("%s\n", ret);
}
That number is:
$2 = {mantissa1 = 0, mantissa0 = 0, quiet_nan = 0, one = 0, exponent = 3280, negative = 0, empty = 0}
which ought to be a perfectly valid floating point number, as far as I can
tell?
It crashes in __mpn_rshift.
726 else if (BITS_PER_MP_LIMB - 1 - cnt_h <= cnt_l)
727 {
728 (void) __mpn_rshift (frac, tmp + i, tmpsize - i,
729 BITS_PER_MP_LIMB - 1 - cnt_h);
730 fracsize = tmpsize - i;
731 }
732 else
(gdb) p frac
$4 = (mp_limb_t *) 0xbfffe73c
(gdb) p *frac
$5 = 0
(gdb) p tmp + i
$6 = (mp_limb_t *) 0xbfffeb20
(gdb) p tmpsize - i
$7 = -450
(gdb) p cnt_h
$8 = 200
-> 64 L(oop): movl (%esi,%edx,4),%ebx /* load next higher limb */
65 shrdl %cl,%ebx,%eax /* compute result limb */
66 movl %eax,(%edi,%edx,4) /* store it */
(gdb) p/x $esi
$5 = 0xbfffe418
(gdb) p/x $edx
$6 = 0x6fa
(gdb) p/x $esi + $edx * 4
$7 = 0xc0000000
i.e. it reads off the stack.
It looks like the problem is the fact that i == 665... but how it got there
involves a maze of twisty little gmp routines, and I have no idea.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux nevyn 2.6.0-test4-nevyn #1 SMP Sat Aug 23 11:19:59 EDT 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl
-- no debconf information
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
---------------------------------------
Received: (at 210981-done) by bugs.debian.org; 15 Sep 2003 13:33:04 +0000
>From drow@crack.them.org Mon Sep 15 08:32:54 2003
Return-path: <drow@crack.them.org>
Received: from dsl093-172-017.pit1.dsl.speakeasy.net (nevyn.them.org) [66.93.172.17]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19ytTH-0005iE-00; Mon, 15 Sep 2003 08:32:51 -0500
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
id 19ytTG-0003lZ-Ip; Mon, 15 Sep 2003 09:32:50 -0400
Date: Mon, 15 Sep 2003 09:32:50 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Vincent Lefevre <vincent@vinc17.org>
Cc: 210981-done@bugs.debian.org
Subject: Re: Bug#210981: libc6: printf crashes on a certain long double
Message-ID: <20030915133250.GA13333@nevyn.them.org>
References: <[🔎] 20030915040027.GA20959@nevyn.them.org> <[🔎] 20030915101047.GA26972@l.ldh.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[🔎] 20030915101047.GA26972@l.ldh.org>
User-Agent: Mutt/1.5.1i
Delivered-To: 210981-done@bugs.debian.org
X-Spam-Status: No, hits=-5.7 required=4.0
tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT
version=2.53-bugs.debian.org_2003_9_14
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_9_14 (1.174.2.15-2003-03-30-exp)
On Mon, Sep 15, 2003 at 07:10:47PM +0900, Vincent Lefevre wrote:
> On Mon, Sep 15, 2003 at 00:00:27 -0400, Daniel Jacobowitz wrote:
> > Package: libc6
> > Version: 2.3.2-7
> > Severity: normal
> >
> > Try it:
> >
> > int data[] = {0x00000000, 0x00000000, 0x00000cd0};
> > struct ieee {
> > unsigned int mantissa1:32;
> > unsigned int mantissa0:30;
> > unsigned int quiet_nan:1;
> > unsigned int one:1;
> > unsigned int exponent:15;
> > unsigned int negative:1;
> > unsigned int empty:16;
> > } *pieee = data;
> > long double *doub = (long double *) data;
> > int main()
> > {
> > char *ret = 0;
> > printf ("%.35Lg\n", *doub);
> > vasprintf (&ret, "%.35Lg", doub);
> > printf ("%s\n", ret);
> > }
> >
> > That number is:
> >
> > $2 = {mantissa1 = 0, mantissa0 = 0, quiet_nan = 0, one = 0, exponent = 3280, negative = 0, empty = 0}
> >
> > which ought to be a perfectly valid floating point number, as far as I can
> > tell?
> [...]
>
> Are you sure? AFAIK, 3280 is not a valid exponent for 0 and the
> first bit of the mantissa must be a 1 (which is represented in
> extended precision) for non-zero normal numbers.
Extended precision represents the one? How odd. Jakub's confirmed
that you're right and the number is garbage, so this is really a GDB
bug... Thank you.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: