Branch: refs/heads/blead
  Home:   https://github.com/Perl/perl5
  Commit: 03e3af819d88d37d65d0aae5f92a351f90f9086b
      
https://github.com/Perl/perl5/commit/03e3af819d88d37d65d0aae5f92a351f90f9086b
  Author: Richard Leach <[email protected]>
  Date:   2026-01-23 (Fri, 23 Jan 2026)

  Changed paths:
    M t/lib/croak/toke

  Log Message:
  -----------
  Add test for GH#16938 assertion failure

The asserting fuzzed case was:

    eval"${sub{sub{//]]]"}}

The assertion triggered was:

    perl​: op.c​:7346​: Perl_newSVOP​: Assertion `sv' failed.

The bug appeared following:
```
commit: 9ffcdca1f504cb09088413c074b35af4b7f247e3
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Mon Nov 12 23​:04​:16 2012 -0800

  Don’t leak subs containing syntax errors

  I fixed this for BEGIN blocks earlier, but missed the fact that
  all subs are affected.

  When called without an o argument (from newANONATTRSUB), newATTRSUB
  is expected to return a CV with an unowned reference count of which
  the caller will take ownership. We cannot have newATTRSUB returning
  a freed CV, so we have it return null instead. But that means
  ck_anoncode and pm_runtime have to account for that.
```

The bug disappeared following:
```
commit eb54d46f7264ff7af62c409d8a6ab984a5a34f57
Author: Yves Orton <[email protected]>
Date:   Fri Aug 26 18:26:14 2022 +0200

    Stop parsing on first syntax error.

    We try to keep parsing after many types of errors, up to a (current)
    maximum of 10 errors. Continuing after a semantic error (like
    undeclared variables) can be helpful, for instance showing a set of
    common errors, but continuing after a syntax error isn't helpful
    most of the time as the internal state of the parser can get confused
    and is not reliably restored in between attempts. This can produce
    sometimes completely bizarre errors which just obscure the true error,
    and has resulted in security tickets being filed in the past.

    This patch makes the parser stop after the first syntax error, while
    preserving the current behavior for other errors. An error is considered
    a syntax error if the error message from our internals is the literal
    text "syntax error". This may not be a complete list of true syntax
    errors, we can iterate on that in the future.

    This fixes the segfaults reported in Issue #17397, and #16944 and
    likely fixes other "segfault due to compiler continuation after syntax
    error" bugs that we have on record, which has been a recurring issue
    over the years.
```



To unsubscribe from these emails, change your notification settings at 
https://github.com/Perl/perl5/settings/notifications

Reply via email to