summaryrefslogtreecommitdiff
path: root/doop.c
diff options
context:
space:
mode:
authorKarl Williamson <khw@cpan.org>2020-11-25 18:20:28 -0700
committerSteve Hay <steve.m.hay@googlemail.com>2021-01-09 12:14:56 +0000
commit4190e73eba88675cc39af83a5c4ac5905e42c7e5 (patch)
tree90bf111d8c96b62a4d6ac76327e9bcabc556610d /doop.c
parent922143f2c5dcd5cc6a0bbea393aee2dd3a2ff523 (diff)
downloadperl-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