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
utf8.c:1418: Perl_utf8n_to_uvchr_error: Assertion `0' failed #15852
Comments
From @dur-randirCreated by @dur-randirWhile fuzzing perl v5.25.8-216-gfbceb79751 built with afl and run s//\3000/; to cause an assertion failure. This is a regression in blead since 94749a5 is the first bad commit Deprecate non-grapheme string delimiter In order for Perl to eventually allow string delimiters to be Unicode GDB info about the crash location: (gdb) bt Perl Info
|
From @khwilliamsonThanks for the report. Fixed by 90b58c7 |
The RT System itself - Status changed from 'new' to 'open' |
@khwilliamson - Status changed from 'open' to 'resolved' |
From @dur-randirOn Wed, 25 Jan 2017 21:42:09 -0800, khw wrote:
This can still be hit by the following 19-bytes program: % hexdump -C ../0045 On debugging builds it gives: Malformed UTF-8 character: \xff\xff (overflows) at ../0045 line 1. On non-debugging builds it produces panic(): Malformed UTF-8 character: \xff\xff (overflows) at ../0045 line 1. |
From @dur-randir |
From @hvdsI can confirm the new case, with: I've reopened the ticket; Sergey, it'd probably be more helpful to send a fresh perlbug report when you find new cases, it's easier to merge tickets that turn out to have the same cause than to separate ones that turn out not to. Hugo |
@hvds - Status changed from 'resolved' to 'open' |
From @dur-randirOn Mon, 30 Jan 2017 09:57:32 -0800, hv wrote:
OK, sure. |
From @dur-randirCreated by @dur-randirWhile fuzzing perl v5.25.9-35-g32207c637b built with afl and run % hexdump -C ../afl-asan/0051_1 to cause an assertion failure. This is a regression in blead, bisect points to: d1f8d42 is the first bad commit utf8.c: Forbid zero-length malformation under DEBUGGING GDB info about the crash location: (gdb) bt Perl Info
|
From @dur-randir |
From @khwilliamsonI have filed #130679 for a portion of this. This ticket is a case in point. There is malformed UTF-8 in it, but we don't know that we are parsing UTF-8 until partway through, after the BEGIN. (Playing manually isn't necessary to get this failure. A 'use utf8' instead also triggers it.) Tony Cook pointed out that replacing the semi-colon with a newline causes the malformedness to be discovered properly. Apparently next_chunk does things a line at a time. He is of the opinion that there may not be a way to efficiently handle the situation where the utf8ness changes midline. Ideas welcome -- |
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 01/30/2017 07:46 PM, Karl Williamson via RT wrote:
should have been (Playing manually with $^H ... |
From @khwilliamsonOn Mon, 30 Jan 2017 12:34:11 -0800, randir wrote:
This reopened ticket is the same cause as 130675, and I have merged them together. We do not handle well the case where the known utf8ness of a file changes mid-line. Outside of fuzzers, that is unlikely to occur in real code. |
From @khwilliamsonThis is now fixed by |
@khwilliamson - 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#130675 (status was 'resolved')
Searchable as RT130675$
The text was updated successfully, but these errors were encountered: