-
Notifications
You must be signed in to change notification settings - Fork 584
panic: invalid pad in intro_my with perl -MO=... and use v5.39* #21981
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
Hmm. Specifically it's about
The panic appears in
169 # define ASSERT_CURPAD_ACTIVE(label) \
170 pad_peg(label); \
171 if (!PL_comppad || (AvARRAY(PL_comppad) != PL_curpad)) \
172 Perl_croak(aTHX_ "panic: invalid pad in %s: 0x%" UVxf "[0x%" UVxf "]",\
173 label, PTR2UV(PL_comppad), PTR2UV(PL_curpad)); Invoked in
I'll have to read more into it to work out why. |
Hrm; gdb doesn't show much more of any real excitement:
|
More excitement: order matters:
|
It looks like AvARRAY() of the saved pad is being modified after the saves:
|
Changing Perl_prepare_export_lexical to use SAVECOMPPAD() fixes it:
Trying to see why |
though I still don't know why. |
When the pad being saved and the pad for PL_compcv is the same, in some cases the actual exports would result in reallocating the AvARRAY() for the saved PL_comppad. The LEAVE in finish_export_lexical() would restore the old PL_comppad (which is fine) and the pre-reallocation PL_curpad (which isn't fine). This would later panic. SAVECOMPPAD; restores PL_comppad on LEAVE and then restores PL_curpad from PL_comppad, preventing the desync between those values. It's unclear to me why only the save_BEGINs; causes this, but the fix does fix a real problem and prevents the panics that I'm aware of here. Fixes Perl#21981
When the pad being saved and the pad for PL_compcv is the same, in some cases the actual exports would result in reallocating the AvARRAY() for the saved PL_comppad. The LEAVE in finish_export_lexical() would restore the old PL_comppad (which is fine) and the pre-reallocation PL_curpad (which isn't fine). This would later panic. SAVECOMPPAD; restores PL_comppad on LEAVE and then restores PL_curpad from PL_comppad, preventing the desync between those values. It's unclear to me why only the save_BEGINs; causes this, but the fix does fix a real problem and prevents the panics that I'm aware of here. Fixes #21981
Uh oh!
There was an error while loading. Please reload this page.
Description
With -DDEBUGGING:
Also
Note this doesn't happen with anything
use v5.38
or less, only 5.39 and higher.According to a bisect this appears to have been introduced here:
The text was updated successfully, but these errors were encountered: