-
Notifications
You must be signed in to change notification settings - Fork 576
BBC: [WIN32] Blead breaks Error-0.17030 #23022
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@sisyphus, would you be able to run this program (from the root directory of a git checkout of Perl 5), suitably adapted for Win32?
|
That test (t/08warndie.t) passes in perl 5.41.1 and 5.41.2 built using visual studio. |
I did see
so there's definitely a problem, debugging further. |
Looks like this is caused by my fix to prevent double-frees of the RExC state interacting with Win32 fork emulation, backtrace:
What I think is happening is:
Some of the other clean up done in release_RExC_state might be duplicated between the two threads too, possibly causing the strange while loop behaviour. Working on a fix (giving RExC_state_t cleanup its own save type) |
Tonyc consider a clone vtable CB if your designing a new api, I never looked too deep at it, but the new "save [stack] onto mortal stack" API, which runs a user C CB with either a RCed SV*, or runs a user C CB with a |
Previous on Win32 this could cause a double-free of the RExC state if an emulated fork was done with the free of the state on the scope stack. Use a custom save type and prevent freeing in the cloned process to prevent the double-free. Fixes Perl#23022
please try #23179 |
I won't be able to test this until I return home (next Monday). |
I'm building and testing it now. (It will take a while.) |
All tests of Error-0.17030 with #23179 passed. The build log for Error-0.17030 is attached. Perl -V output:
Thank you, |
388bf71 (ignoring Perl#23022 for now) ensured that the RExC_state and its controlled pointers were freed once and only once, regardless of whether re_op_compile() returned normally or threw an exception. Unfortunately that free could happen very later, surviving well beyond when the regexp was compiled. Add an ENTER/LEAVE pair to ensure the cleanup is done immediately on a normal return.
LGTM, too. |
Previous on Win32 this could cause a double-free of the RExC state if an emulated fork was done with the free of the state on the scope stack. Use a custom save type and prevent freeing in the cloned process to prevent the double-free. Fixes Perl#23022
388bf71 (ignoring Perl#23022 for now) ensured that the RExC_state and its controlled pointers were freed once and only once, regardless of whether re_op_compile() returned normally or threw an exception. Unfortunately that free could happen very later, surviving well beyond when the regexp was compiled. Add an ENTER/LEAVE pair to ensure the cleanup is done immediately on a normal return.
388bf71 (ignoring #23022 for now) ensured that the RExC_state and its controlled pointers were freed once and only once, regardless of whether re_op_compile() returned normally or threw an exception. Unfortunately that free could happen very later, surviving well beyond when the regexp was compiled. Add an ENTER/LEAVE pair to ensure the cleanup is done immediately on a normal return.
UPDATE: Version 0.17030 is a recent release, but the same issue arises with the previous version (0.17029).
Breakage begins with perl-5.41.3, and also afflicts perl-5.40.1.
The problem exists all the way through to current blead (commit 3df6082).
The crash occurs after the 3rd iteration of the following while{} loop (located at line 46 of t/08warndie.t ):
The assignment
$s .= $_
is attempted only 3 times - and those attempts are successful.Yet, we never get to successfully exit the loop.
Perl -V output:
The text was updated successfully, but these errors were encountered: