On Wed, 05 Jun 2019 10:39:48 GMT, hv wrote: > On Mon, 03 Jun 2019 21:15:59 -0700, hv wrote: > > On Mon, 03 Jun 2019 19:22:56 -0700, jkeenan wrote: > > > #13 0x00000000004f4788 in Perl_vcroak (my_perl=0x801e22000, > > > pat=0x801f56838 "\030 �\001\b", args=0x7fffffffe680) at util.c:1711 > > > #14 0x00000000004f1b27 in Perl_croak_nocontext (pat=<value > > > optimized > > > out> ) at util.c:1745 > > > #15 0x000000000044c57e in Perl_sys_term () at perl.c:146 > > > #16 0x0000000000421472 in main (argc=<value optimized out>, > > > argv=<value optimized out>, env=0x7fffffffe770) > > > at perlmain.c:155 > > > > We're in sys_term, so most of the interpreter has already been wiped > > out, but we're then calling croak(), which relies on the > > interpreter's > > infrastructure. > [...] > > I'll try harder to reproduce it: I'd need some interactive gdb work > > to > > diagnose it. > > I still cannot reproduce here. Please could you try getting another > stacktrace with the attached patch applied, to narrow down which bit > of Perl_sys_term() we're in? > > To help with subsequent tests, it would also be useful to narrow down > the testcase. Please check if any of these reproduce the SEGV: > ./perl -e 'my $x = sprintf("%7000000000E", 0)' > ./perl -e 'eval { my $x = sprintf("%7000000000E", 0) }; print > "ok\n"' > the attached sprintf2-short.t, with all but the new test removed > (The previously reported backtrace was from a version of t/op/sprintf2.t with all tests but the final one commented out.) See attachment, hugo-results-20190605.txt. -- James E Keenan (jkeenan@cpan.org) --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=134172Thread Previous | Thread Next