This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Avoid deadlock with PERL_MEM_LOG
authorKarl Williamson <khw@cpan.org>
Thu, 26 Nov 2020 01:20:28 +0000 (18:20 -0700)
committerKarl Williamson <khw@cpan.org>
Fri, 27 Nov 2020 04:03:07 +0000 (21:03 -0700)
commit0cc28fe31b0d416e9c67ecd18b8f38c5833a455a
treebdb3eacf8a75747f7fe51f7bf72f3ba0d9a1d145
parent5640a370e8b19af74b8ca0b4694464c21a87916b
Avoid deadlock with PERL_MEM_LOG

This fixes GH #18341

The Perl wrapper for getenv() was changed in 5.32 to allocate memory to
squirrel safely away the result of the wrapped getenv() call.  It does
this while in a critical section so as to make sure another thread can't
interrupt it and destroy it.

Unfortunately, when Perl is compiled for debugging memory problems and
has PERL_MEM_LOG enabled, that allocation causes a recursive call to
getenv() for the purpose of checking an environment variable to see how
to log that allocation.  And hence it deadlocks trying to enter the
critical section.

There are various solutions.  One is to use or emulate a general semaphore
instead of a binary one.  This is effectively what
PL_lc_numeric_mutex_depth does for another mutex, and the code for that
could be used as a template.

But given that this is an extreme edge case which requires Perl to be
specially compiled to enable this feature which is used only for
debugging, a much simpler, if less safe if it were to ever be used in
production, solution should suffice.  Tony Cook suggested just avoiding
the wrapper for this particular purpose.
util.c