On Sat Feb 28 18:29:21 2015, sprout wrote: > I finally finished tracking this down. It’s PL_lex_defer again. So > the fix is nearly identical to #123801. See commit 479ae48. Unfortunately I'm still seeing the additional two cases failing; apologies that I didn't clarify before they should not have a trailing newline: % echo -n '"\L\L"' | ./miniperl -c Segmentation fault (core dumped) % echo -n '<\L\L>' | ./miniperl -c Segmentation fault (core dumped) % They're both failing at the same place now. (The first was previously crashing at perly.c:423.) Program received signal SIGSEGV, Segmentation fault. S_SvREFCNT_dec (sv=0xa22) at inline.h:162 162 U32 rc = SvREFCNT(sv); (gdb) where #0 S_SvREFCNT_dec (sv=0xa22) at inline.h:162 #1 Perl_yyparse (gramtype=gramtype@entry=258) at perly.c:532 #2 0x000000000040fa4b in S_parse_body (xsinit=0x43fda0 <xs_init>, env=0x0) at perl.c:2277 #3 perl_parse (my_perl=<optimized out>, xsinit=xsinit@entry=0x43fda0 <xs_init>, argc=<optimized out>, argv=<optimized out>, env=env@entry=0x0) at perl.c:1611 #4 0x00000000004066c0 in main (argc=3, argv=0x7fffffffe638, env=0x7fffffffe658) at miniperlmain.c:120 (gdb) I confirmed (against the first) that it does bisect to 7aa8cb0de. Hugo --- via perlbug: queue: perl5 status: pending release https://rt.perl.org/Ticket/Display.html?id=123802Thread Previous | Thread Next