Front page | perl.perl5.porters |
Postings from June 2019
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
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134172
Thread Previous
|
Thread Next