GNU bug report logs - #47067
28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Thu, 11 Mar 2021 11:28:02 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #293 received at 47067 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47067 <at> debbugs.gnu.org
Subject: Re: bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling
 through dispnew.c
Date: Sun, 21 Mar 2021 16:41:14 +0000
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 47067 <at> debbugs.gnu.org
>> Date: Sun, 21 Mar 2021 15:41:48 +0000
>> 
>> I was thinking, the only downside I see of this solution is that while
>> we can tweak the build system to signal to Emacs that a certain file
>> being compiled will be used for dump, this will indeed not be possible
>> for subsequent dumps.
>
> I don't think I follow: why would this be impossible for subsequent
> dumps?
>
> Maybe I should describe the use case this is supposed to solve.
> Imagine a repository where Emacs is being built regularly, and where
> old Emacs builds are kept for long periods of time, together with
> their *.pdmp files.  So we will have emacs-28.0.50.1, emacs-28.0.50.2,
> ... emacs-28-0.50.1000, ..., and their respective *.pdmp files.  The
> intent is to be able to run these old binaries for quick "bisecting"
> of issues reported by users.  This is what I do on my system: I keep
> one build from each of the previous months, and delete the rest.
>
> Until native-comp, keeping the binary and the .pdmp file was enough
> for being able to run that binary.  With native-comp, we also need the
> *.eln files that were dumped into each of the *.pdmp files.  I'm
> trying to find a reasonable solution to this problem.

Thanks I think I've understood the case.

I was referring to a different case, future dumps done by the user
calling directly `dump-emacs-portable', in that case some .eln might
stay where they were placed originally (not in the preloaded subfolder).

I know for now we don't support officially `dump-emacs-portable' to be
used directly by the user, so I'm not sure that's a real issue, but I
was trying to think future proof.

Thanks

  Andrea




This bug report was last modified 4 years and 45 days ago.

Previous Next


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