On Tue, 24 Jan 2017 00:19:10 -0800, randir wrote: > While fuzzing perl v5.25.8-216-gfbceb79751 built with afl and run > under libdislocator, I found the following program > > s//'x' ^ -"s:\347"/eeg > > to cause a memory leak report under ASAN: > > ================================================================= > ==27209==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4 byte(s) in 1 object(s) allocated from: > #0 0x4ea6c8 in malloc (/home/afl/afl-asan/perl+0x4ea6c8) > #1 0x8504be in Perl_safesysmalloc /home/afl/afl-asan/util.c:153:21 > #2 0x8564ab in Perl_savepvn /home/afl/afl-asan/util.c:1177:5 > #3 0x675843 in Perl_yylex /home/afl/afl-asan/toke.c:7027:23 > #4 0x6f6072 in Perl_yyparse /home/afl/afl-asan/perly.c:340:34 > #5 0xb0c78f in S_doeval_compile /home/afl/afl- > asan/pp_ctl.c:3432:77 > #6 0xb09a17 in Perl_pp_entereval /home/afl/afl- > asan/pp_ctl.c:4292:9 > #7 0x84b114 in Perl_runops_debug /home/afl/afl-asan/dump.c:2406:23 > #8 0x5f1b05 in S_run_body /home/afl/afl-asan/perl.c:2528:2 > #9 0x5f1b05 in perl_run /home/afl/afl-asan/perl.c:2451 > #10 0x5224d2 in main /home/afl/afl-asan/perlmain.c:123:9 > #11 0x7efca17d02b0 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) > > SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). > > Leaked scalar comes from the following line > > pl_yylval.pval = savepvn(PL_tokenbuf, len+1); > > In this case PL_tokenbuf is "Us" and len == 2. Amount of memory leaked > scales with the size of this buffer. For example, the following > eternal loop leaks 20 bytes per iteration, so run it with caution: > > s//'x' ^ -"s666666666666666k:\347"/eeg while (1) This looks like it's fixed, I expect by: commit 017192018b7f9fc4b889bb344bd75df8f6b78929 Author: David Mitchell <davem@iabyn.com> Date: Fri Apr 5 12:49:50 2019 +0100 parser: change LABEL type from pval to opval The items pushed onto the parser stack can be one of several types: ival, opval, pval etc. The only remaining use of pval is when a "label:" is encountered. When an error occurs during parsing, ops on the parse stack get automatically reaped these days as part of the OP slab mechanism; but bare strings (pvals) still leak. Convert this one remaining pval into an opval, making the toker return an OP_CONST with an SV holding the label. Since newSTATEOP() still expects a raw string for the label, the parser just grabs the value returned by the toker and makes a copy of the string from it, then immediately frees the OP_CONST and its associated SV. The leak was showing up in ext/XS-APItest/t/stmtasexpr.t, which expects to parse a statement where labels are banned. Tony --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=130632