Subject: bug#50268: 28.0.50; Assertion warning during native compilation

From: "Basil L. Contovounesios" <[email-masked]>
Date: Tue, 21 Sep 2021 13:17:18 +0100

Andrea Corallo [2021-09-21 07:50 +0000] wrote:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <[email-masked]> writes:
>
>> Michael Welsh Duggan <[email-masked]> writes:
>>
>>> I was able to determine that there was a bug in the pacproxy.el code
>>> that I included in the bug report.  Fixing that bug caused native
>>> compilation to work.  The assertion and backtrace were not particularly
>>> useful in determining the bug in the code, though.  The bug was in the
>>> `pacproxy--retrieve-wpad' function when I let-bound the following
>>> illegal lambda:
>>>
>>>   (lambda (&rest) "DIRECT")
>>>
>>> The fix was to change this to:
>>>
>>>   (lambda (&rest _) "DIRECT")
>>>
>>> Is there another part of the compiler that could have caught this and
>>> returned a useful diagnostic?
>>
>> Hi Michael & all,
>>
>> I had a quick look and these are my findings:
>>
>> (byte-compile '(lambda (&rest _) "DIRECT"))
>> =>
>> #[128 "\300\207" ["DIRECT"] 2 "DIRECT
>>
>> (fn &rest _)"]
>>
>> Here we have as encoded signature 128 (one rest arg) and the frame size
>> is 2 (one for the rest arg and one for the immediate). Fine...
>>
>> (byte-compile '(lambda () "DIRECT"))
>> =>
>> #[0 "\300\207" ["DIRECT"] 1 "DIRECT"] 
>>
>> Here we have as encoded signature 0 (no args) and the frame size is 1
>> (will be used by the immediate).  Fine as well.
>>
>> (byte-compile '(lambda (&rest) "DIRECT"))
>> =>
>> #[128 "\300\207" ["DIRECT"] 1 "DIRECT
>>
>> (fn &rest)"]
>>
>> This is the problematic case that was signaled as reproducer.  Here we
>> have as encoded signature 128 (one rest arg) but the frame size (1) is
>> not accounting for this.
>>
>> I think this output is a incoherent and I guess the byte compiler should
>> probably just raise an error and refuse to compile if the lambda list is
>> invalid.  Am I wrong?
>
> I can't verify in this moment but I guess is very possible we even
> overflow in the byte interpreter when executing the mentioned bytecode.

In the meantime I think Mattias ran into the same problem in the
following threads:

https://lists.gnu.org/r/emacs-devel/2021-09/msg01492.html
https://bugs.gnu.org/50720

Thanks,

-- 
Basil