diff options
author | Karl Williamson <khw@cpan.org> | 2020-11-25 18:20:28 -0700 |
---|---|---|
committer | Steve Hay <steve.m.hay@googlemail.com> | 2021-01-09 12:14:56 +0000 |
commit | 4190e73eba88675cc39af83a5c4ac5905e42c7e5 (patch) | |
tree | 90bf111d8c96b62a4d6ac76327e9bcabc556610d /doop.c | |
parent | 922143f2c5dcd5cc6a0bbea393aee2dd3a2ff523 (diff) | |
download | perl-4190e73eba88675cc39af83a5c4ac5905e42c7e5.tar.gz |
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.
(cherry picked from commit 0cc28fe31b0d416e9c67ecd18b8f38c5833a455a)
Diffstat (limited to 'doop.c')
0 files changed, 0 insertions, 0 deletions