Assert fail in gv.c without other symptoms: use re%:=0 #15358
Comments
From @dcollinsnGreetings Porters, I have compiled bleadperl with the afl-gcc compiler using: ./Configure -Dusedevel -Dprefix='/usr/local/perl-afl' -Dcc='ccache afl-gcc' -Uuselongdouble -Duse64bitall -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -Dusequadmath -des And then fuzzed the resulting binary using: AFL_NO_VAR_CHECK=1 afl-fuzz -i in -o out bin/perl @@ After reducing testcases using `afl-tmin` and performing additional minimization by hand, I have located the following testcase that triggers an assert fail in debug buids of the perl interpreter. The testcase is the file below. On normal builds, this throws the expected error. On debug builds, this returns an assert fail. use re%:=0 dcollins@nightshade64:~/perl$ ./perl -Ilib -e "use re%:=0" Debugging tool output is below. A git bisect was performed and reported the following, which is the commit in which the assert was initially added. 9075437 is the first bad commit gv_check(): use aux flag rather than IsCOW Currently the SVf_IsCOW flag doesn't have any meaning for HVs, This then potentially frees up the SVf_IsCOW for use as a new general flag :100644 100644 42cd69cb1626c962cf97c9516e254119919d0680 4a10f9b8adf98fe5f2dc72888ab3dcbcd08ef77f M gv.c **GDB** (gdb) run Program received signal SIGABRT, Aborted. **VALGRIND** dcollins@nightshade64:~/perldebug$ valgrind ./perl -Ilib -e "use re%:=0" **PERL -V** dcollins@nightshade64:~/perldebug$ ./perl -Ilib -V Characteristics of this binary (from libperl): |
From @cpansproutOn Wed May 25 15:58:12 2016, dcollinsn@gmail.com wrote:
Less noisy version: use less %: = 0
The assertion seems to be wrong. In fact, it seems that a BEGIN-time require *and* %: assignment are sufficient to trigger it. I don’t understand why ‘require’ is affecting it. It happens with re.pm and less.pm, but not utf8.pm, so presumably a line of code common to the first two is helping to trigger this. $ ./miniperl -Ilib -e 'BEGIN { require re; %: = 0}' -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Wed May 25 18:11:15 2016, sprout wrote:
Anything that enables warnings (of course, since without warnings enabled at least somewhere gv_check doesn’t get called). $ ./miniperl -Ilib -e 'BEGIN { %: = 0; $^W=1}' -- Father Chrysostomos |
From @iabynOn Wed, May 25, 2016 at 08:12:32PM -0700, Father Chrysostomos via RT wrote:
Fixed with this: commit e7acdfe only treat stash entries with .*:: as sub-stashes -- |
|
@cpansprout - Status changed from 'open' to 'pending release' |
From @cpansproutOn Tue Jun 21 09:12:49 2016, davem wrote:
Apologies if this sounds rude, but that is not a very robust fix. This code is naughty, but it still should not crash: $ ./perl -Ilib -MDevel::Peek -e 'BEGIN { -- Father Chrysostomos |
|
@cpansprout - Status changed from 'pending release' to 'open' |
From @iabynOn Wed, Jun 22, 2016 at 01:23:47PM -0700, Father Chrysostomos via RT wrote:
Ah, so its still possible to put substash-like entries in stashes that I don't know whether the correct fix is stashify values put into stashes This isn't an area I'm very conversant with. Do you have any opinions? -- |
From @cpansproutOn Thu Jun 23 05:57:27 2016, davem wrote:
Since this code is just for a warning, I would suggest skipping sub-stashes that are not SvOOK. In fact, if we do that at the beginning of gv_check, we don’t need to check HvARRAY (we can switch the conditions in the if() and the assert() around). In fact, I might go ahead and write the patch within the next day or two. :-) -- Father Chrysostomos |
From @cpansproutOn Thu Jun 23 06:36:48 2016, sprout wrote:
Fixed in 9e5cda6. -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.26.0, this and 210 other issues have been Perl 5.26.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#128238 (status was 'resolved')
Searchable as RT128238$
The text was updated successfully, but these errors were encountered: