Front page | perl.perl5.porters |
Postings from June 2019
On Mon, 10 Jun 2019 12:24:19 GMT, jkeenan wrote:
> On Mon, 10 Jun 2019 11:53:37 GMT, hv wrote:
> > On Thu, 06 Jun 2019 10:30:58 -0700, jkeenan wrote:
> > > Watchpoint 2: PL_locale_mutex
> > >
> > > Old value = 0x801e1c1e0
> > > New value = 0x2
> > > _pthread_mutex_destroy (mutex=0xa45b28) at pthread_md.h:95
> > > 95 return (TCB_GET64(tcb_thread));
> >
> > Ok, I can make sense of this bit now: the pthread_mutex_destroy code
> > explicitly overwrites the pointer to signal that it has been
> > destroyed:
> >
> > /usr/src/lib/libthr/thread/thr_private.h has:
> > #define THR_MUTEX_DESTROYED ((struct pthread_mutex *)2)
> > /usr/src/lib/libthr/thread/thr_mutex.c has:
> > *mutex = THR_MUTEX_DESTROYED;
> > in multiple cases.
> >
> > So this isn't corruption but intentional. The core of the problem,
> > though, is that we're seeing an error returned from the
> > mutex_destroy,
> > which is what is triggering our attempt to croak. And the error turns
> > out to be EBUSY, indicating that we're trying to destroy a mutex that
> > is still locked, and with the debug option -DLv it becomes trivial to
> > see that:
> >
> > $ ./perl -Ilib -DLv -we 'my $x = sprintf("%2E", 0)'
> > sv.c: 12972: locking lc_numeric; depth=1
> > sv.c: 13422: unlocking lc_numeric; depth=0
> >
> > EXECUTING...
> >
> > $ ./perl -Ilib -DLv -we 'my $x = sprintf("%7000000000E", 0)'
> > sv.c: 12972: locking lc_numeric; depth=1
> >
> > EXECUTING...
> >
> > sv.c: 12972: avoided lc_numeric_lock; new depth=2
> > Numeric format result too large at -e line 1.
> > Segmentation fault (core dumped)
> > $
> >
> > We're invoking STORE_LC_NUMERIC_SET_TO_NEEDED, which is documented
> > with:
> > On threaded perls not operating with thread-safe functionality,
> > this
> > macro uses
> > a mutex to force a critical section. Therefore the matching
> > RESTORE
> > should be
> > close by, and guaranteed to be called.
> > .. however this is wrapping precisely the call with the new error
> > check, so when that croaks the RESTORE_LC_NUMERIC is missed, and that
> > causes us to attempt global destruction with the mutex still held.
> >
> > Because there are 2 nested calls to the STORE macro, I'm not sure how
> > correct the obvious fix is; there also seems to be some cleverness
> > with pragmas to try and enforce balancing of STORE/RESTORE. I was
> > able
> > to get it both to compile and run the test case without error with
> > the
> > attached, but I think it's Karl's baby so I hope he can advise.
> >
> > Note also: a) there are other opportunities to hit fatal errors in
> > sprintf, I assume they'll all need the same handling; b) the
> > 'mutex_destroy or croak' pattern makes no sense after
> > PerlIO_teardown(), but I'm not sure what we can do instead - the bug
> > uncovered here certainly suggests we'd have been unwise simply to
> > ignore errors on mutex_destroy.
> >
> > Hugo
>
> Thanks. I realize your patch is preliminary, but to get some data
> from other platforms, I've placed it in this branch:
>
> smoke-me/jkeenan/hv/134172-hack
>
> Thank you very much.
Smoke results are looking good. I intend to merge this branch into blead within 24 hours unless we get bad results or someone objects.
TonyC, does this look okay to you?
Hugo, would you like to suggest a better commit message?
Thank you very much.
--
James E Keenan (jkeenan@cpan.org)
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134172
Thread Previous
|
Thread Next