Front page | perl.perl5.porters |
Postings from June 2019
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=134172
Thread Previous
|
Thread Next