From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id 744B83858C27 for ; Wed, 17 Nov 2021 09:21:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 744B83858C27 Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 1AH9L8aA029433 for ; Wed, 17 Nov 2021 18:21:08 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 1AH9L8aA029433 X-Nifty-SrcIP: [110.4.221.123] Date: Wed, 17 Nov 2021 18:21:08 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: possible snprintf() regression in 3.3.2 Message-Id: <20211117182108.b38599f5e13071bf269a0d48@nifty.ne.jp> In-Reply-To: <20211117003718.GF10332@venus.tony.develop-help.com> References: <20211117003718.GF10332@venus.tony.develop-help.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 09:21:28 -0000 On Wed, 17 Nov 2021 11:37:18 +1100 Tony Cook wrote: > This came up from regression testing perl. > > Regression testing of perl @4a1b9dd524007193213d3919d6a331109608b90c > used (from uname): > > cygwin_nt-10.0 fv-az177-186 3.3.1(0.34153) 2021-10-28 20:52 x86_64 cygwin > > this did not exhibit the problem. See https://github.com/Perl/perl5/runs/4084168038?check_suite_focus=true > > Testing of perl @a85e04e2281234a61c051f8f3ff63bed7381902c, the next > commit, which is purely a documentation change did exhibit the bug, used: > > cygwin_nt-10.0 fv-az177-290 3.3.2(0.34153) 2021-11-08 16:55 x86_64 cygwin > > which did crash. See https://github.com/Perl/perl5/runs/4159124596?check_suite_focus=true > > snprintf() appears to be crashing internally to ldtoa_r(), without > cygwin-debuginfo the backtrace is: > > Thread 1 "perl" received signal SIGSEGV, Segmentation fault. > 0x00007ffd26b21548 in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > (gdb) bt > #0 0x00007ffd26b21548 in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #1 0x00007ffd26b21040 in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #2 0x00007ffd26b20e7b in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #3 0x00007ffd26b413a8 in ntdll!RtlRaiseException () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #4 0x00007ffd26b90bfe in ntdll!KiUserExceptionDispatcher () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #5 0x00000001801fec7c in eiremain () from /usr/bin/cygwin1.dll > #6 0x0000000180200319 in _ldtoa_r () from /usr/bin/cygwin1.dll > #7 0x00000001801cfca9 in _svfprintf_r () from /usr/bin/cygwin1.dll > #8 0x00000001801bf327 in snprintf () from /usr/bin/cygwin1.dll > #9 0x000000018018eb0b in _sigfe () from /usr/bin/cygwin1.dll > #10 0x0000000052162647 in Perl_sv_vcatpvfn_flags (my_perl=0x80004a3e0, > sv=0x800ca9e78, pat=0x523a3501 "%.9f", > patlen=4, args=0xffffc550, svargs=0x0, sv_count=0, maybe_tainted=0x0, > flags=0) at sv.c:13482 > #11 0x000000005215e360 in Perl_sv_vsetpvfn (my_perl=0x80004a3e0, > sv=0x800ca9e78, pat=0x523a3501 "%.9f", > patlen=4, args=0xffffc550, svargs=0x0, sv_count=0, maybe_tainted=0x0) > at sv.c:11271 > #12 0x000000005215dde9 in Perl_sv_vsetpvf (my_perl=0x80004a3e0, > sv=0x800ca9e78, pat=0x523a3501 "%.9f", > args=0xffffc550) at sv.c:11101 > #13 0x000000005215dd6a in Perl_sv_setpvf (my_perl=0x80004a3e0, sv=0x800ca9e78, > pat=0x523a3501 "%.9f") at sv.c:11076 > #14 0x000000005210aa74 in Perl_upg_version (my_perl=0x80004a3e0, > ver=0x800cacb00, qv=false) at /home/tony/dev/perl/git/perl/vutil.c:700 > #15 0x00000000520440a4 in XS_universal_version (my_perl=0x80004a3e0, > cv=0x80004dfa0) at /home/tony/dev/perl/git/perl/vxs.inc:122 > #16 0x0000000052142b10 in Perl_pp_entersub (my_perl=0x80004a3e0) > at pp_hot.c:5361 > #17 0x00000000521318e7 in Perl_runops_standard (my_perl=0x80004a3e0) > at run.c:41 > #18 0x00000000520376ff in S_run_body (my_perl=0x80004a3e0, oldscope=1) > at perl.c:2715 > #19 0x0000000052037214 in perl_run (my_perl=0x80004a3e0) at perl.c:2643 > #20 0x000000010040117c in main (argc=4, argv=0xffffcc00, env=0x8000281a0) > at perlmain.c:110 > > With cygwin-debuginfo installed the backtrace is: > > Thread 1 "perl" received signal SIGSEGV, Segmentation fault. > 0x00007ffd26b21548 in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > (gdb) bt > #0 0x00007ffd26b21548 in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #1 0x00007ffd26b21040 in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #2 0x00007ffd26b20e7b in ntdll!RtlVirtualUnwind () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #3 0x00007ffd26b413a8 in ntdll!RtlRaiseException () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #4 0x00007ffd26b90bfe in ntdll!KiUserExceptionDispatcher () > from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > #5 0x00000001801fec7c in eiremain (den=0x1, num=0x0, ldp=0x5) > at /usr/src/debug/cygwin-3.3.2-1/newlib/libc/stdlib/ldtoa.c:3736 > #6 0x00000001802bb0b0 in etens () from /usr/bin/cygwin1.dll > #7 0x00000000ffffbac2 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > The stack appears to be badly corrupted (etens isn't a function). I found the caused by the commit: commit 4d90e5335914551862831de3e02f6c102b78435b Author: Corinna Vinschen Date: Thu Nov 4 11:30:44 2021 +0100 ldtoa: fix dropping too many digits from output ldtoa cuts the number of digits it returns based on a computation of number of supported bits (144) divide by log10(2). Not only is the integer approximation of log10(2) ~= 8/27 missing a digit here, it also fails to take really small double and long double values into account. Allow for the full potential precision of long double values. At the same time, change the local string array allocation to request only as much bytes as necessary to support the caller-requested number of digits, to keep the stack size low on small targets. In the long run a better fix would be to switch to gdtoa, as the BSD variants, as well as Mingw64 do. Signed-off-by: Corinna Vinschen Reverting this commit solves the problem. Corinna, could you please have a look? -- Takashi Yano