NetBSD Problem Report #56247

From woods@xentastic.weird.com  Tue Jun 15 05:36:35 2021
Return-Path: <woods@xentastic.weird.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 2C2501A921F
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 15 Jun 2021 05:36:35 +0000 (UTC)
Message-Id: <20210615053632.B694D511CA@xentastic.weird.com>
Date: Mon, 14 Jun 2021 22:36:32 -0700 (PDT)
From: "Greg A. Woods" <woods@planix.ca>
Reply-To: "Greg A. Woods" <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Subject: printf("%La", LDBL_MIN) dumps core
X-Send-Pr-Version: 3.95

>Number:         56247
>Category:       lib
>Synopsis:       printf("%La", LDBL_MIN) dumps core
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 15 05:40:00 +0000 2021
>Last-Modified:  Thu May 09 12:25:04 +0000 2024
>Originator:     Greg A. Woods
>Release:        NetBSD 9.99.81
>Organization:
Planix, Inc.; Kelowna, BC; Canada
>Environment:
System: NetBSD xentastic 9.99.81 NetBSD 9.99.81 (XEN3_DOM0) #16: Thu May 6 13:40:07 PDT 2021 woods@xentastic:/build/woods/xentastic/current-amd64-amd64-obj/build/src/sys/arch/amd64/compile/XEN3_DOM0 amd64
Architecture: x86_64
Machine: amd64
Source-Date: 2021-03-10T23:08:13Z
>Description:

	Playing with printing floating point numbers today and I
	encountered the following core dump.

	(This is from a static-linked build -- the frames in jemalloc
	look a little more weird in the dynamic-linked build, but
	otherwise it starts out the same in a call to free() in
	libc/gdtoa/misc.c.)

Reading symbols from t-ldbl-min...
[New process 19842]
Core was generated by `t-ldbl-min'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  atomic_load_p (mo=atomic_memory_order_relaxed, a=0x3418)
    at /build/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/atomic_gcc_atomic.h:31
31              not_reached();
(gdb) bt
#0  atomic_load_p (mo=atomic_memory_order_relaxed, a=0x3418)
    at /build/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/atomic_gcc_atomic.h:31
#1  rtree_leaf_elm_bits_read (dependent=true, elm=0x3418, 
    rtree=<optimized out>, tsdn=<optimized out>)
    at /build/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/rtree.h:175
#2  rtree_szind_slab_read (r_slab=<synthetic pointer>, 
    r_szind=<synthetic pointer>, dependent=true, key=6829440, 
    rtree_ctx=0x781687442028, rtree=<optimized out>, tsdn=<optimized out>)
    at /build/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/rtree.h:464
#3  ifree (slow_path=false, tcache=0x7816874421c0, ptr=0x683580 <private_mem>, 
    tsd=<optimized out>)
    at /build/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2243
#4  free (ptr=0x683580 <private_mem>)
    at /build/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2433
#5  0x000000000041557b in __Bfree_D2A (v=<optimized out>)
    at /build/src/lib/libc/gdtoa/misc.c:104
#6  0x000000000041503e in __freedtoa (s=<optimized out>)
    at /build/src/lib/libc/gdtoa/dmisc.c:100
#7  0x000000000040f917 in __vfprintf_unlocked_l (
    fp=fp@entry=0x682918 <__sF+152>, loc=0x6822a0 <_lc_global_locale>, 
    fmt0=fmt0@entry=0x467214 "%La\n", ap=ap@entry=0x7f7fff934018)
    at /build/src/lib/libc/stdio/vfwprintf.c:1105
#8  0x00000000004110d2 in vfprintf (fp=0x682918 <__sF+152>, 
    fmt0=fmt0@entry=0x467214 "%La\n", ap=ap@entry=0x7f7fff934018)
    at /build/src/lib/libc/compat/../locale/setlocale_local.h:93
#9  0x000000000040bfe2 in printf (fmt=fmt@entry=0x467214 "%La\n")
    at /build/src/lib/libc/stdio/printf.c:59
#10 0x0000000000467015 in main () at t-ldbl-min.c:10
(gdb) 

>How-To-Repeat:

	compile and run the following on amd64

#include <float.h>
#include <stdio.h>
#include <stdlib.h>

int main(void);

int
main()
{
	printf("%La\n", LDBL_MIN);

	exit(0);
}

>Fix:
	unknown

>Audit-Trail:
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56247 CVS commit: src/lib/libc/gdtoa
Date: Tue, 15 Jun 2021 06:56:52 -0400

 Module Name:	src
 Committed By:	christos
 Date:		Tue Jun 15 10:56:52 UTC 2021

 Modified Files:
 	src/lib/libc/gdtoa: hdtoa.c

 Log Message:
 PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core
 Don't write to ((char *)malloc(size))[-1];


 To generate a diff of this commit:
 cvs rdiff -u -r1.11 -r1.12 src/lib/libc/gdtoa/hdtoa.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56247 CVS commit: src
Date: Thu, 9 May 2024 12:24:24 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Thu May  9 12:24:24 UTC 2024

 Modified Files:
 	src/lib/libc/gdtoa: hdtoa.c
 	src/tests/lib/libc/stdio: t_printf.c

 Log Message:
 Revert various broken changes to printf %La (hldtoa).

 This reverts:

 hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core)
 hdtoa.c 1.11 (fix tyop)
 hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of
     EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).)

 The underlying motivation for this change was that when ld128 is
 decomposed into 4x32 words, this hldtoa logic is broken.

 But we don't decompose ld128 into 4x32 words; we decompose it into
 6x64 words.

 And the change, which was supposed to be a noop in our case of 2x64
 words (or similar for x87 80-bit floating-point), broke it to the
 point of causing buffer overruns (PR 56247) which when worked around
 led to just incorrect output output (PR 56937).

 If we want to make the #ifdefs for 4x32 words work, that's fine, but
 we absolutely must have automatic test cases to detect this kind of
 regression because %La formatting is extremely important for
 diagnosing details of floating-point data since it doesn't involve
 rounding in binary formats.  For now I've added some trivial tests;
 there is a more extensive test suite inside gdtoa that we need to
 wire up before anyone tries any other shenanigans in this code.

 PR lib/56937: printf(3) long double %a formatting is broken


 To generate a diff of this commit:
 cvs rdiff -u -r1.12 -r1.13 src/lib/libc/gdtoa/hdtoa.c
 cvs rdiff -u -r1.14 -r1.15 src/tests/lib/libc/stdio/t_printf.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Home	PR Database Search