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 sv.c with no further symptoms: e t''/$0{\0} #15340
Comments
From @dcollinsnI 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 -DDEBUGGING -des And then fuzzed the resulting binary using: AFL_NO_VAR_CHECK=1 afl-fuzz -i in -o out bin/perl -t -W @@ After reducing testcases using `afl-tmin` and performing additional minimization by hand, I have located the following testcase that triggers an assert fail in debugging builds of the perl interpreter. The testcase is the file below. On normal builds, this exits with the expected error. On debug builds with -W, this returns an assert fail. dcollins@nightshade64:~$ perl/miniperl -W -e 'e t""/$0{\0}' Debugging tool output is below. A git bisect was attempted, but this persists as far back as 5.14.0, which is also as far back as I'm able to compile right now. **GDB** dcollins@nightshade64:~$ gdb --args perldebug/miniperl -W -e 'e t""/$0{\0}' Program received signal SIGABRT, Aborted. **PERL -V** dcollins@nightshade64:~$ perl/perl -V Characteristics of this binary (from libperl): |
From @dcollinsnThe slightly shorter testcase: perl -W -e 'e f/$0{\0}/' also shows this error |
From @dcollinsnI really should finish looking through my queue before posting. Best testcase is the 8-character file: miniperl -W -e '0/$0{\0}' |
From @cpansproutOn Thu May 19 14:53:18 2016, dcollinsn@gmail.com wrote:
Shorter: perl -we '"$0{\0}"' Any uninitialized warning that tries to mention $0{\0} will trigger it. -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Thu May 19 15:02:05 2016, sprout wrote:
It appears that the subscript has to be an OP_CONST, because qr// doesn’t trigger it. A bisect points to: commit 04698ff [perl #79178] STORE/FETCH of tie()d hash get stringified key but that is a red herring. It fixed another bug, exposing this one. Here is a similar bug with array indices. There is no crash here, but the number in the subscript is bogus: $ ./miniperl -we '"$0[\0]"' I would expect the output of the latter command to match the subscript in the uninit warning. -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
$ perl -le 'printf "%x\n", 1753414896' The index has been truncated to 32 bits, that's all. -zefram |
From @cpansproutOn Thu May 19 15:33:41 2016, zefram@fysh.org wrote:
I thought it might be that. I was too lazy to check. That itself is also a bug, though. -- Father Chrysostomos |
From @iabynOn Thu, May 19, 2016 at 05:18:31PM -0700, Father Chrysostomos via RT wrote:
The original issue is now fixed with v5.25.2-15-g55b6481. -- |
@iabyn - Status changed from 'open' to 'resolved' |
From @cpansproutOn Tue Jun 21 07:29:25 2016, davem wrote:
The AV API was changed to support 64-bit indices some time ago (e.g. v5.19.3-99-gc70927a), but report_uninit_var got left behind. I have fixed it in commit 1b3df0e. -- Father Chrysostomos |
Migrated from rt.perl.org#128189 (status was 'resolved')
Searchable as RT128189$
The text was updated successfully, but these errors were encountered: