[Top][All Lists]

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

Re: Regression in dump-emacs-portable

From: Lynn Winebarger
Subject: Re: Regression in dump-emacs-portable
Date: Thu, 16 Feb 2023 20:29:34 -0500

On Thu, Feb 16, 2023 at 10:46 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >  > Almost every library in 28.2 could be redumped, excepting those which
> >  > simply failed to load for whatever reason.
> >
> >  Don't we have Lisp objects that cannot be dumped?  If we do, then not
> >  every library could be dumped even in principle.
> >
> > In 28.2, using dump-emacs-portable, the answer is, not many in the 
> > libraries in included in the Emacs
> > source distribution.  I excluded the term and obsolete subdirectories from 
> > generating the set of libraries to
> > dump (but not from the final set determined from load-history).
> Is exclusion really the way to go, if we want eventually to support
> re-dumping at any given moment?

At the moment, my concern is just with keeping the functionality 28.2
has for redumping, unless there is some deliberate tradeoff being
I'm just using exclusion until I can automate a more precise
determination of what is dumpable and what isn't.  Also, some of those
libraries may be included in the dump - I'm only excluding them from
the set used to generate the list of libraries to include in the dump.
I probably could have narrowed down the problematic libraries, but I
didn't want to spend a lot of time manually investigating why
libraries classified as obsolete were causing problems.  On the term
side, it seemed that the ones causing issues were either due to
incompatibility (win32 on linux, say) or perhaps required some feature
not available in batch mode, so just attempting to load them caused
problems.  More precise lists of expected failures can be created.

> >  Another potential issue with this is (assuming you suggest to actually
> >  try dumping every library) that it will take too long, and thus will
> >  be likely to be skipped in any "normal" run of the test suite, thus
> >  missing the point.
> >
> > My 2017-vintage laptop dumps the 1252 files, including all of leim, in 34 
> > seconds, for a 135MB dump file.
> > When I added leim to the exclusions list,  1172 libraries are dumped in 24 
> > seconds for a 83MB dump file,
> > which explains why my effort with 30.0.50 produces a 75MB dump.
> That's a lot.  And I presume your build is optimized?  So an
> unoptimized build will be slower.  Running such slow tests routinely
> is a PITA, so such a test will probably moved to a category that
> doesn't run by default.

It's fine with me if the tests aren't run directly by the developer,
unless they're particularly concerned about it.  I'd expect pdumper
functionality to require testing on multiple platforms anyway, not
just whatever system the developer is using.
I can pick some that are causing failures now, but I have no idea why
they stress the current implementation.  icomplete causes an abort in
131ms.  sh-script generates a "weird pseudovector" message in 376ms
> time emacs -Q -batch --eval '(load "icomplete")' --eval '(dump-emacs-portable 
> "test-icomplete.pdmp")'
Loading icomplete...
Dumping fingerprint:
Fatal error 6: Aborted
Aborted (core dumped)

real 0m0.131s
user 0m0.102s
sys 0m0.029s
> time emacs -Q -batch --eval '(load "sh-script")' --eval '(dump-emacs-portable 
> "test-sh-script.pdmp")'
Loading sh-script...
Dumping fingerprint:

Error: error ("unsupported object type in dump: weird pseudovector")
  mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode
  debug-early(error (error "unsupported object type in dump: weird
  eval((dump-emacs-portable "test-sh-script.pdmp") t)
  command-line-1(("--eval" "(load \"sh-script\")" "--eval"
"(dump-emacs-portable \"test-sh-script.pdmp\")"))
unsupported object type in dump: weird pseudovector

real 0m0.376s
user 0m0.172s
sys 0m0.040s

> > Aside from testing on a per-commit basis, isn't there a
> > more comprehensive set of regression tests run pre-release? Does emacs have 
> > a CI process regularly
> > running the test suite, or is it more ad hoc?
> There's EMBA.

Ok, that's the kind of thing I was thinking of. I'll read over the
relevant admin/notes before asking more questions.
I'm going to put some more work into automating generation of
comprehensive redumping scripts this weekend.  Once I have that I can
look into how to use that process to generate regression tests for
specified sets of libraries to redump.


reply via email to

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