our sub nesting and eval yields crash #21067
Labels
Comments
|
tonycoz
added a commit
to tonycoz/perl5
that referenced
this issue
Jun 8, 2023
Fixes Perl#21067 but a WIP, needs a better commit message and test.
tonycoz
added a commit
to tonycoz/perl5
that referenced
this issue
Jun 9, 2023
Fixes Perl#21067 When an instance of a closure is created, the pad entries for the cloned sub are copied (S_clone_sv_pad()) from either the prototype sub (for lexicals belonging to the sub) or from the context (for lexicals from outside the sub). This doesn't happen for our variables, instead the cloned sub has these pad entries set to NULL. This isn't an issue at runtime since references to lexical our sub/variables are compiled into GV or GVSV ops. cv_undef_flags() assumed this these entries were non-NULL for all lexical subs. Fix by checking if the entry is an our sub and the CV being freed is a clone, if so, skip the accesses to the NULL pad entry. Added an assert to the new branch to ensure any changes in the above results in an early failure here and hopefully a fix.
tonycoz
added a commit
that referenced
this issue
Jul 25, 2023
Fixes #21067 When an instance of a closure is created, the pad entries for the cloned sub are copied (S_clone_sv_pad()) from either the prototype sub (for lexicals belonging to the sub) or from the context (for lexicals from outside the sub). This doesn't happen for our variables, instead the cloned sub has these pad entries set to NULL. This isn't an issue at runtime since references to lexical our sub/variables are compiled into GV or GVSV ops. cv_undef_flags() assumed this these entries were non-NULL for all lexical subs. Fix by checking if the entry is an our sub and the CV being freed is a clone, if so, skip the accesses to the NULL pad entry. Added an assert to the new branch to ensure any changes in the above results in an early failure here and hopefully a fix.
steve-m-hay
pushed a commit
that referenced
this issue
Oct 6, 2024
Fixes #21067 When an instance of a closure is created, the pad entries for the cloned sub are copied (S_clone_sv_pad()) from either the prototype sub (for lexicals belonging to the sub) or from the context (for lexicals from outside the sub). This doesn't happen for our variables, instead the cloned sub has these pad entries set to NULL. This isn't an issue at runtime since references to lexical our sub/variables are compiled into GV or GVSV ops. cv_undef_flags() assumed this these entries were non-NULL for all lexical subs. Fix by checking if the entry is an our sub and the CV being freed is a clone, if so, skip the accesses to the NULL pad entry. Added an assert to the new branch to ensure any changes in the above results in an early failure here and hopefully a fix. (cherry picked from commit 59b7881)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Message ID: [email protected]
This is a bug report for perl from zefram at fysh.org,
generated with the help of perlbug 1.44 running under perl 5.37.11.
Necessary elements to get this crash: named sub declared with "our"
(rather than "my" or "state" or as a package sub); closure sub
(either anonymous sub or "my" sub); string eval use compiled inside
closure sub; reference to the named sub compiled inside closure sub;
closure constructed at runtime. Non-requirements: string eval
doesn't need to execute; reference to the named sub doesn't need to
execute; order of the string eval and sub reference doesn't matter;
closure doesn't need to be called.
Adding "-Mfeature=lexical_subs", this crash occurs all the way
back to Perl 5.17.4 when lexical subs were first introduced.
Flags
Perl configuration
The text was updated successfully, but these errors were encountered: