-
Notifications
You must be signed in to change notification settings - Fork 560
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
Assert fail in S_find_uninit_var (via Perl_pp_multideref) without other symptoms: $ISA[0][0] #15364
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 runs normally (albeit with an expected warning). On debug builds, this returns an assert fail. dcollins@nightshade64:~/perl$ ./perl -Ilib -W -e '$ISA[0][0]' dcollins@nightshade64:~/perl$ cd ../perldebug/ dcollins@nightshade64:~/perldebug$ ./perl -Ilib -W -e '$ISA[0][0]' Debugging tool output is below. A git bisect was performed and reported the following. fedf30e is the first bad commit Add OP_MULTIDEREF This op is an optimisation for any series of one or more array or hash So all of the following are replaced with a single op: $h{foo} while these aren't: $a[0] already handled by OP_AELEMFAST and these are partially replaced: (expr)->[0]{$k} the bit following (expr) is replaced Up until now, aggregate dereferencing has been very heavyweight in ops; for gv[*r] s When executing this, in addition to the actual calls to av_fetch() and The multideref op avoids that by running all the code in a loop in a typedef union { In something like $a[7][$i]{foo}, the GVs or pad offsets for @a and $i are Then the main body of pp_multideref is a big while loop round a switch, Note that there is a slight complication with /DEREF; in the example above aelem sKM/DREFHV,2 which means that the aelem, after having retrieved a (possibly undef) In terms of benchmarking with Porting/bench.pl, a simple lexical Overall, Ir 100.00 145.00 COND_m 100.00 127.65 with cache misses unchanged at 100%. In general, the more lookups done, the bigger the proportionate saving. :100644 100644 4775d8ee963455f92943ec5801667f52c27d4cc8 7d04e1f4a95ce2052bf6d2edf5bb37f626fa81bb M MANIFEST **GDB** dcollins@nightshade64:~/perldebug$ gdb --args ./perl -Ilib -W -e '(($ISA[0][0]))' Program received signal SIGABRT, Aborted. **VALGRIND** No reported memory management errors. **PERL -V** dcollins@nightshade64:~/perldebug$ ./perl -Ilib -V Characteristics of this binary (from libperl): |
From @iabynOn Thu, May 26, 2016 at 05:08:31PM -0700, Dan Collins wrote:
Fixed by the below: commit 6fe82bd handle magic in multideref "unit val" var names -- |
The RT System itself - Status changed from 'new' to 'open' |
@iabyn - 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#128253 (status was 'resolved')
Searchable as RT128253$
The text was updated successfully, but these errors were encountered: