On Wed, 05 Jun 2019 05:39:11 -0700, jkeenan wrote: > (The previously reported backtrace was from a version of > t/op/sprintf2.t with all tests but the final one commented out.) Ah ok; since the first one-liner is enough to reproduce the crash, I suggest sticking with that for further testing: ./perl -e 'my $x = sprintf("%7000000000E", 0)' [...] > #16 0x000000000044c596 in Perl_sys_term () at perl.c:152 > #17 0x0000000000421472 in main (argc=<value optimized out>, argv=<value optimized out>, env=0x7fffffffe758) > at perlmain.c:155 That looks like it is in the line: LOCALE_TERM; /* PL_locale_mutex */ .. and since this is one of the mutex destroy calls that happens _after_ we've torn down the perlio system it's no surprise that attempting to croak() goes badly. From here I'll need some help: I'm not sure how to refer to the location of this mutex for a threaded build in gdb - I was expecting it to be something like 'my_vars->Glocale_mutex', but at least on my local build that's not recognised. If someone can tell us that, the next step will be to run the test in gdb with a hardware watchpoint on the mutex. That'll look something like this: shell% gdb --args ./perl -e 'my $x = sprintf("%7000000000E", 0)' (gdb) # first let the interpreter initialise (gdb) tbreak perlmain.c:126 (gdb) run Temporary breakpoint 1, main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perlmain.c:126 126 if (!perl_parse(my_perl, xs_init, argc, argv, (char **)NULL)) (gdb) watch PL_locale_mutex # replace with appropriate expression to refer to this mutex (gdb) run Hopefully that would then stop somewhere other than in the MUTEX_DESTROY, and a stack trace will show us where and how the corruption is occurring. Hugo --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=134172Thread Previous | Thread Next