[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: an "internal compiler error"

From: Jose E. Marchesi
Subject: Re: an "internal compiler error"
Date: Tue, 14 Feb 2023 12:08:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

> Jose E. Marchesi wrote:
>> > $ poke -l /tmp/fuzz1.pk 
>> > 1:1: internal compiler error: input buffer overflow, can't enlarge buffer 
>> > because scanner uses REJECT
>> > Important information has been dumped in /tmp/pokecyGfH0.
>> > Please attach it to a bug report and send it to poke-devel@gnu.org.
>> > Aborted
>> >
>> > Credit: AFL++4.00.c
>> Yes we are aware of that.
>> It is a fatal error that flex generates when it needs to grow a buffer
>> but the lexer uses REJECT (as in our case).
> So, in this particular case, wouldn't it be better to lonjmp() back to the
> main REPL prompt, rather than to ask for a bug report to poke-devel?

Yes, but I don't think we can discriminate between that particular error
and other fatal errors raised by flex.

See YY_FATAL_ERROR in libpoke/pkl-lex.l.  The only argument we get in
that macro is the error message.  We could scan it and try to determine
whether we should longjmp or abort, but that would be rather fragile

So we would need to recover in all sort of flex fatal errors.  Since a
new scanner is created each time pk_compile_* is invoked, that may be

reply via email to

[Prev in Thread] Current Thread [Next in Thread]