GNU bug report logs - #55972
28.1; Package quickstart generated for large number of packages generates byte-code string larger than 64K, triggering bytecode overflow error

Previous Next

Package: emacs;

Reported by: Lynn Winebarger <owinebar <at> gmail.com>

Date: Tue, 14 Jun 2022 14:52:02 UTC

Severity: normal

Found in version 28.1

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>, 55972 <at> debbugs.gnu.org
Subject: bug#55972: 28.1; Package quickstart generated for large number of packages generates byte-code string larger than 64K, triggering bytecode overflow error
Date: Fri, 17 Jun 2022 17:27:23 -0400
> I was going to ask about directly addressing the underlying problem by
> tail-calling or trampolining to a byte-code vector in the constants
> array, but then realized you would have to either make sure there
> could be no "gotos" between the segments or do a real trampoline to an
> explicit label.  And in either case you would have to save the
> contents of the stack frame and reinstate them in the continuation
> byte-code call, and I don't see any byte-codes that would support
> that.   Otherwise you could only do it when you know there is no stack
> in use, which is what I believe your solution effectively does.

Indeed, the 64k limit can bite hard in some cases where working around
it would take a lot of work and we don't have any of the infrastructure
needed for it.

But luckily, in practice those hard cases tend not to occur at all.
Instead we tend to bump into the limit just because we're too naive in
how we combine together several top-level expressions.

> As long as I'm looking at the compile log, I also see a lot of errors of
> the form:
>      package-quickstart2.el:14739:39: Warning: The compiler ignores
> ‘autoload’ except at top level.  You should
>          probably put the autoload of the macro ‘bind-map-for-minor-mode’
> at top-level.

Could you make a separate bug report for this one?
I'm not sure what's the better fix for this one.  It should be a harmless
warning, but even when it's harmless it's annoying.


        Stefan





This bug report was last modified 1 year and 276 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.