From: Lynn Winebarger <owinebar@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Regression in dump-emacs-portable
Date: Thu, 16 Feb 2023 20:29:34 -0500 [thread overview]
Message-ID: <CAM=F=bCr+vvZSeusCSpupOYuRZvi0-Uv0aUvbuTacvfoq60_jQ@mail.gmail.com> (raw)
In-Reply-To: <83o7pt395q.fsf@gnu.org>
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
made.
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:
30c4a01f07c30c32913a3c578aa6871d7af188212b14e2f9c5e3717f80b9ab43
Fatal error 6: Aborted
Backtrace:
emacs(emacs_backtrace+0x37)[0x55ec89e6de67]
emacs(terminate_due_to_signal+0x6f)[0x55ec89d33514]
emacs(nsberror+0x0)[0x55ec89d33726]
emacs(+0x21f9da)[0x55ec89ebb9da]
emacs(+0x21efc7)[0x55ec89ebafc7]
emacs(+0x2203a1)[0x55ec89ebc3a1]
emacs(Fdump_emacs_portable+0xb70)[0x55ec89ebd070]
emacs(eval_sub+0x9b3)[0x55ec89edc1d3]
emacs(Feval+0x3f)[0x55ec89ede22f]
emacs(exec_byte_code+0x482)[0x55ec89f1e182]
emacs(+0x2412fc)[0x55ec89edd2fc]
emacs(eval_sub+0x2bc)[0x55ec89edbadc]
emacs(Feval+0x3f)[0x55ec89ede22f]
emacs(internal_condition_case+0x3e)[0x55ec89ed6c7e]
emacs(+0x1b4618)[0x55ec89e50618]
emacs(internal_catch+0x3d)[0x55ec89ed6bed]
emacs(+0x1b2998)[0x55ec89e4e998]
emacs(recursive_edit_1+0x86)[0x55ec89e54d56]
emacs(Frecursive_edit+0xd0)[0x55ec89e550f0]
emacs(main+0x190f)[0x55ec89d35c5f]
/lib64/libc.so.6(__libc_start_main+0xef)[0x7fb49dd4129d]
emacs(_start+0x2a)[0x55ec89d369ea]
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:
30c4a01f07c30c32913a3c578aa6871d7af188212b14e2f9c5e3717f80b9ab43
Error: error ("unsupported object type in dump: weird pseudovector")
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode
-0x7c3fa1856517817>))
debug-early-backtrace()
debug-early(error (error "unsupported object type in dump: weird
pseudovector"))
dump-emacs-portable("test-sh-script.pdmp")
eval((dump-emacs-portable "test-sh-script.pdmp") t)
command-line-1(("--eval" "(load \"sh-script\")" "--eval"
"(dump-emacs-portable \"test-sh-script.pdmp\")"))
command-line()
normal-top-level()
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.
Thanks,
Lynn
next prev parent reply other threads:[~2023-02-17 1:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 0:51 Regression in dump-emacs-portable Lynn Winebarger
2023-02-14 1:13 ` Lynn Winebarger
2023-02-14 14:23 ` Eli Zaretskii
2023-02-14 23:26 ` Lynn Winebarger
2023-02-15 12:42 ` Eli Zaretskii
2023-02-16 9:31 ` Lynn Winebarger
2023-02-16 9:54 ` Lynn Winebarger
2023-02-16 15:05 ` Lynn Winebarger
2023-02-16 15:34 ` Eli Zaretskii
2023-02-16 23:45 ` Lynn Winebarger
2023-02-17 13:22 ` Lynn Winebarger
2023-02-17 14:31 ` Eli Zaretskii
2023-02-17 23:44 ` Lynn Winebarger
2023-02-18 7:07 ` Eli Zaretskii
2023-02-21 14:21 ` Lynn Winebarger
2023-02-23 2:41 ` Lynn Winebarger
2023-02-23 13:21 ` Lynn Winebarger
2023-02-16 15:46 ` Eli Zaretskii
2023-02-17 1:29 ` Lynn Winebarger [this message]
2023-02-17 3:19 ` Lynn Winebarger
2023-02-17 4:10 ` Lynn Winebarger
2023-02-17 5:21 ` Po Lu
2023-02-17 12:57 ` Lynn Winebarger
2023-02-23 15:08 ` Gregory Heytings
2023-02-23 22:32 ` Lynn Winebarger
2023-02-25 4:11 ` Richard Stallman
2023-02-25 4:11 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM=F=bCr+vvZSeusCSpupOYuRZvi0-Uv0aUvbuTacvfoq60_jQ@mail.gmail.com' \
--to=owinebar@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).