On Tue, 04 Jun 2019 04:15:59 GMT, hv wrote: > On Mon, 03 Jun 2019 19:22:56 -0700, jkeenan wrote: > > On Tue, 04 Jun 2019 01:15:35 GMT, hv wrote: > > > On Mon, 03 Jun 2019 17:14:02 -0700, jkeenan@pobox.com wrote: > > > > The following smoke test indicates that a recent change to blead > > > > is > > > > causing failures in t/op/sprintf2.t on FreeBSD-11. > > > [...] > > > > op/sprintf2.t (Wstat: 2304 Tests: 1699 Failed: 0) > > > > Non-zero exit status: 9 > > > > > > It's this non-zero exit status that's making it a fail. That's > > > reporting that it terminated with a SEGV. > > > > I haven't used gdb in years, so I'm fumbling around. > > > > Does this help? > > Well, it is exactly what I asked for. > > > #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. > > My best guess is that we're hitting 'Perl_croak_nocontext("panic: > MUTEX_UNLOCK (%d) [%s:%d]" ...)' in one of the MUTEX_UNLOCK calls, and > some wild writes have corrupted both one of our mutexes and perhaps > this panic string. > > It seems like it'd be hard for it to get this far with that level of > corruption though. > > I'll try harder to reproduce it: I'd need some interactive gdb work to > diagnose it. > > Hugo This is now showing up on other OSes. See: http://perl5.test-smoke.org/submatrix?test=../t/op/sprintf2.t&pversion=5.31.1 -- James E Keenan (jkeenan@cpan.org) --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=134172Thread Previous | Thread Next