SEGV reading through null HEK* in hv_ename_add #14512
Comments
From @hvdsAFL (<http://lcamtuf.coredump.cx/afl/>) finds this: % ./miniperl -e '%0=*:=*::::=0' The code looks similar to the glob overwriting cases in [perl #123710], but the failure mode is quite different: Program received signal SIGSEGV, Segmentation fault. Not sure what's supposed to be happening here - the else branch (when not aux->xhv_name_count) clearly knows when it stores existing_name to xhvnameu_names[0] that it might be NULL, that's why our name_count is -2, so how can it be right to loop as far as xhvnameu_names[0] in the if branch? Hugo |
From @cpansproutOn Mon Feb 16 04:37:51 2015, hv wrote:
Bisect: 1f656fc is the first bad commit Followup to 088225f/[perl #88132]: packages ending with : -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Mon Mar 02 22:09:39 2015, sprout wrote:
Here is a clearer example, which goes back to 5.14: $ ./miniperl -e '%0; *bar::=*foo::=0' The %0 hash needs to be vivified beforehand, and the two globs assigned to need to be stash globs (fq names ending in ::). The logic in hv_ename_add is wrong, and probably has been so since I wrote it. -- Father Chrysostomos |
From @cpansproutFixed in 3d50185. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for submitting this ticket. The issue should now be resolved with the release today of Perl v5.22, which is available at http://www.perl.org/get.html |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#123847 (status was 'resolved')
Searchable as RT123847$
The text was updated successfully, but these errors were encountered: