GNU bug report logs - #34114
27.0.50: pdumper and themes with Emacs daemon

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34114 in the body.
You can then email your comments to 34114 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Karl Otness <karl <at> karlotness.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50: pdumper and themes with Emacs daemon
Date: Thu, 17 Jan 2019 11:15:54 +0000

I have some issues with theme loading with recent master (978cf88) in
daemon mode. The problem seems to have been introduced with pdumper in
d12e5d00. This is on an Arch Linux system.

After starting an Emacs daemon I see messages about invalid faces:
"face-attribute: Invalid face: tooltip".

The error seems to be signaled from xfaces.c:1866 and called through
`frame-notice-user-settings', and `frame-set-background-mode' all
working with the initial frame F1.

After connecting my first (graphical GTK) client some of my theme
settings have not been applied. In my case, the default face is plain
black text. Doing another manual `load-theme' fixes the settings.

To reproduce with recent master, load a theme in init.el for example
"(load-theme 'wombat)", start a new daemon (I was using fg-daemon) and
connect a client. The messages buffer should have the error message. I
manage to reproduce with an init.el that is just the `load-theme'
call.

I'm also getting a crash with `report-emacs-bug' that looks like
bug#34051, so here are the features manually:

"XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD JSON
CANNOT_DUMP LCMS2 GMP"

Thanks,
Karl

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

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: 34114 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>
Subject: 27.0.50: pdumper and themes with Emacs daemon
Date: Thu, 17 Jan 2019 15:01:23 -0500

[Message part 1 (text/plain, inline)]

Hello,

I ended up on the exact same issue today which I reported on the devel
mailing list: https://lists.gnu.org/r/emacs-devel/2019-01/msg00361.html.

I'll be now tracking this issue here. Please CC me in all the replies.

--
Kaushal Modi

[Message part 2 (text/html, inline)]

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

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: 34114 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>
Subject: Re: 27.0.50: pdumper and themes with Emacs daemon
Date: Thu, 17 Jan 2019 15:38:25 -0500

[Message part 1 (text/plain, inline)]

Hello Daniel,

I am replying to your suggestion from
https://lists.gnu.org/r/emacs-devel/2019-01/msg00372.html in this debbugs
thread:

> It's worth testing this sort of weirdness with --with-dumping=unexec too.

I recompiled emacs master with --with-dumping=unexec added to configure.

With that, my theme is loading correctly as before, and also that tooltip
face warning went away.

--
Kaushal Modi

[Message part 2 (text/html, inline)]

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

From: Karl Otness <karl <at> karlotness.com>
To: 34114 <at> debbugs.gnu.org
Cc: Daniel Colascione <dancol <at> dancol.org>,
 Kaushal Modi <kaushal.modi <at> gmail.com>
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Fri, 18 Jan 2019 23:02:14 +0000

I think I have found a change that fixes this issue. I haven't tested
it too thoroughly, but it seems to work for me. The change is to call
init_faces_initial from init_display_interactive even when Emacs is
running as daemon.

In init_display_interactive in dispnew.c moving the lines:

> /* Set up faces of the initial terminal frame.  */
> if (!noninteractive && NILP (Vinitial_window_system))
>   init_faces_initial ();

from the end of the function so that they occur before the early
return in the IS_DAEMON check (around line 6039) seems to fix the
theme loading problem.

Thanks,
Karl

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Karl Otness <karl <at> karlotness.com>
Cc: 34114 <at> debbugs.gnu.org, Kaushal Modi <kaushal.modi <at> gmail.com>
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Fri, 18 Jan 2019 18:23:33 -0500

[Message part 1 (text/html, inline)]

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

From: Karl Otness <karl <at> karlotness.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 34114 <at> debbugs.gnu.org
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Fri, 18 Jan 2019 23:37:33 +0000

If you could take care that I would appreciate it. I haven't done the
copyright paperwork.

Thanks,
Karl

On Fri, Jan 18, 2019 at 11:24 PM Daniel Colascione <dancol <at> dancol.org> wrote:
>
> Looks reasonable to me. Want to install it?

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Karl Otness <karl <at> karlotness.com>
Cc: 34114 <at> debbugs.gnu.org
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Fri, 18 Jan 2019 18:49:38 -0500

[Message part 1 (text/html, inline)]

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

From: Karl Otness <karl <at> karlotness.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 34114 <at> debbugs.gnu.org
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Sat, 19 Jan 2019 00:09:18 +0000

[Message part 1 (text/plain, inline)]

I might have exhausted those limits as well with a few other changes.
I've prepared and attached a patch that makes the change I described
above, but I'm not sure if it can be installed as-is without the
copyright paperwork.

Thanks,
Karl


On Fri, Jan 18, 2019 at 11:50 PM Daniel Colascione <dancol <at> dancol.org> wrote:
>
> Should fall under the de minimus exception to paperwork requirements

[0001-Initialize-faces-in-daemon-mode-with-pdumper-Bug-341.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Karl Otness <karl <at> karlotness.com>
Cc: 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Sat, 19 Jan 2019 09:05:48 +0200

> From: Karl Otness <karl <at> karlotness.com>
> Date: Fri, 18 Jan 2019 23:02:14 +0000
> Cc: Kaushal Modi <kaushal.modi <at> gmail.com>
> 
> I think I have found a change that fixes this issue. I haven't tested
> it too thoroughly, but it seems to work for me. The change is to call
> init_faces_initial from init_display_interactive even when Emacs is
> running as daemon.
> 
> In init_display_interactive in dispnew.c moving the lines:
> 
> > /* Set up faces of the initial terminal frame.  */
> > if (!noninteractive && NILP (Vinitial_window_system))
> >   init_faces_initial ();
> 
> from the end of the function so that they occur before the early
> return in the IS_DAEMON check (around line 6039) seems to fix the
> theme loading problem.

Thanks for identifying the code that's involved in this.

However, I'm not yet sure the solution you propose is the correct
one.  The way the code is written, it relies on the faces of the
initial frame to be initialized when Emacs is built, and then recorded
in the dumped Emacs.  With the pdumper approach, the record should be
in the emacs.pdmp file, and I'd expect it to be restored from there.

Why isn't this working?

If we want to repeat this initialization in the daemon when it starts
up, I'd like first to better understand the considerations for this
kind of situations: when we should fix such problems by recording and
restoring them to/from the dump file, and when we should run the
initialization code anew in the dumped Emacs.  The latter might mean
we cause more trouble elsewhere, because a lot of the code that runs
during startup expects stuff done in temacs to be available and ready
to use, not recomputed anew.

Daniel, can you comment on this aspect of the problem, including on
the more general issue?

In any case, if the proposed change is installed, it should not affect
the unexeced Emacs, so it IMO should be conditioned on
dumped_with_pdumper_p.  Unexeced Emacs should continue behaving as it
did before.

Thanks.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>, Karl Otness <karl <at> karlotness.com>
Cc: 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Mon, 21 Jan 2019 17:59:46 -0500

On 1/19/19 2:05 AM, Eli Zaretskii wrote:
>> From: Karl Otness <karl <at> karlotness.com>
>> Date: Fri, 18 Jan 2019 23:02:14 +0000
>> Cc: Kaushal Modi <kaushal.modi <at> gmail.com>
>>
>> I think I have found a change that fixes this issue. I haven't tested
>> it too thoroughly, but it seems to work for me. The change is to call
>> init_faces_initial from init_display_interactive even when Emacs is
>> running as daemon.
>>
>> In init_display_interactive in dispnew.c moving the lines:
>>
>>> /* Set up faces of the initial terminal frame.  */
>>> if (!noninteractive && NILP (Vinitial_window_system))
>>>    init_faces_initial ();
>>
>> from the end of the function so that they occur before the early
>> return in the IS_DAEMON check (around line 6039) seems to fix the
>> theme loading problem.
> 
> Thanks for identifying the code that's involved in this.
> 
> However, I'm not yet sure the solution you propose is the correct
> one.  The way the code is written, it relies on the faces of the
> initial frame to be initialized when Emacs is built, and then recorded
> in the dumped Emacs.  With the pdumper approach, the record should be
> in the emacs.pdmp file, and I'd expect it to be restored from there.
> 
> Why isn't this working?
> 
> If we want to repeat this initialization in the daemon when it starts
> up, I'd like first to better understand the considerations for this
> kind of situations: when we should fix such problems by recording and
> restoring them to/from the dump file, and when we should run the
> initialization code anew in the dumped Emacs.  The latter might mean
> we cause more trouble elsewhere, because a lot of the code that runs
> during startup expects stuff done in temacs to be available and ready
> to use, not recomputed anew.
> 
> Daniel, can you comment on this aspect of the problem, including on
> the more general issue?
> 
> In any case, if the proposed change is installed, it should not affect
> the unexeced Emacs, so it IMO should be conditioned on
> dumped_with_pdumper_p.  Unexeced Emacs should continue behaving as it
> did before.

In general, we should try do as much work as possible in the initial 
dump, just as we do in unexeced Emacs. Frames, however, are special 
because we can't actually save and restore frames. Any frame object 
comes back, after pdumper load, as an all-nil object. Since faces are 
attached to frames, and since after pdumper load, we have all-new 
frames, we need to re-add the default faces. Kaushal's change seems like 
the right sort of fix. All of this is very confusing and we should 
probably totally rethink it after we remove unexec.

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

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34114 <at> debbugs.gnu.org,
 Karl Otness <karl <at> karlotness.com>
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Tue, 22 Jan 2019 11:28:57 -0500

[Message part 1 (text/plain, inline)]

On Mon, Jan 21, 2019 at 5:59 PM Daniel Colascione <dancol <at> dancol.org> wrote:

Kaushal's change seems like
> the right sort of fix.


That was Karl :)

I am simply using unexec for now.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Tue, 22 Jan 2019 18:45:20 +0200

> Cc: 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
> From: Daniel Colascione <dancol <at> dancol.org>
> Date: Mon, 21 Jan 2019 17:59:46 -0500
> 
> In general, we should try do as much work as possible in the initial 
> dump, just as we do in unexeced Emacs. Frames, however, are special 
> because we can't actually save and restore frames. Any frame object 
> comes back, after pdumper load, as an all-nil object.

What is special about frames that precludes them from being recorded
by the pdumper?  Since the startup code is written under the
assumption that a frame is available with some minimal functionality,
I'm afraid this face issue could be the tip of a large iceberg.  E.g.,
many customizations in users' .emacs files might stop working if we
don't have an initial frame like we had in unexeced version.

> All of this is very confusing and we should probably totally rethink
> it after we remove unexec.

I wholeheartedly agree.  Unexec was invented to record loaded Lisp
code, but with time it ended up accruing a lot of stuff that is only
tangentially related to Lisp, or even not at all.  However,
rearranging all that and removing all the cruft we no longer need is a
formidable job, so I think we should embark on that only after we have
a reliable baseline, a pdumper version that works as well as the
unexeced one.  And it will take us some time to find and fix any
remaining bugs and then become convinced that we've reached that goal.

So I'd like first to have a pdumper version that works as close to the
unexec version, and only after that start moving/removing the
initialization code from temacs to emacs.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Tue, 22 Jan 2019 17:41:34 -0800

On 1/22/19 8:45 AM, Eli Zaretskii wrote:
>> Cc: 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
>> From: Daniel Colascione <dancol <at> dancol.org>
>> Date: Mon, 21 Jan 2019 17:59:46 -0500
>>
>> In general, we should try do as much work as possible in the initial
>> dump, just as we do in unexeced Emacs. Frames, however, are special
>> because we can't actually save and restore frames. Any frame object
>> comes back, after pdumper load, as an all-nil object.
> 
> What is special about frames that precludes them from being recorded
> by the pdumper?

Frames contain instance-specific state, and I don't think it makes sense 
to try to pretend that individual frames survive from one Emacs 
invocation to another. We definitely want to record customizations that 
affect frames generally (like face definitions), but IMHO, we should do 
that in a way that doesn't depend on preserving any frame in particular.

>  Since the startup code is written under the
> assumption that a frame is available with some minimal functionality,
> I'm afraid this face issue could be the tip of a large iceberg.  E.g.,
> many customizations in users' .emacs files might stop working if we
> don't have an initial frame like we had in unexeced version.

We do have an initial frame: we just make it anew when we start Emacs. 
When we set a face attribute, we set it for new frames as well by 
calling Finternal_set_lisp_face_attribute with frame being Qt, which 
ends up updating face-new-frame-defaults, which we do preserve in a 
pdumped image. If these defaults aren't being applied to frames we 
create after pdumper load, there's a bug.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Wed, 23 Jan 2019 05:43:26 +0200

> Cc: karl <at> karlotness.com, 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
> From: Daniel Colascione <dancol <at> dancol.org>
> Date: Tue, 22 Jan 2019 17:41:34 -0800
> 
> > What is special about frames that precludes them from being recorded
> > by the pdumper?
> 
> Frames contain instance-specific state, and I don't think it makes sense 
> to try to pretend that individual frames survive from one Emacs 
> invocation to another.

Sorry, I still don't think I understand: what is that
instance-specific state, in terms of members of the frame object, or
its attributes?

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Tue, 22 Jan 2019 20:05:40 -0800

[Message part 1 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Wed, 23 Jan 2019 07:32:25 +0200

On January 23, 2019 6:05:40 AM GMT+02:00, Daniel Colascione <dancol <at> dancol.org> wrote:
> 
> 
> 
> On Jan 22, 2019 7:43 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Cc: karl <at> karlotness.com, 34114 <at> debbugs.gnu.org,
> kaushal.modi <at> gmail.com 
> > From: Daniel Colascione <dancol <at> dancol.org> 
> > Date: Tue, 22 Jan 2019 17:41:34 -0800 
> > 
> > > What is special about frames that precludes them from being
> recorded 
> > > by the pdumper? 
> > 
> > Frames contain instance-specific state, and I don't think it makes
> sense 
> > to try to pretend that individual frames survive from one Emacs 
> > invocation to another. 
> 
> Sorry, I still don't think I understand: what is that 
> instance-specific state, in terms of members of the frame object, or 
> its attributes? 
> 
> 
> A frame is always associated with a specific pty, specific X11 window,
> specific win32 window, etc. These concepts do not exist across
> different invocations of Emacs. I don't understand what you don't
> understand. 

I didn't understand what you meant by "instance".  I think I do now -- you mean output_method, output_data, and terminal members of struct frame?  If so, these are (trivially) figured out for the initial frame, they are set to special values.  And we delete that initial frame during startup, as soon as we can.  So I don't think I understand the concerns.  What specific problems could be caused by retaining this initial frame?

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Tue, 22 Jan 2019 22:48:59 -0800

[Message part 1 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 34114 <at> debbugs.gnu.org, karl <at> karlotness.com, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Thu, 24 Jan 2019 17:11:56 +0200

> Date: Tue, 22 Jan 2019 22:48:59 -0800
> From: Daniel Colascione <dancol <at> dancol.org>
> Cc: karl <at> karlotness.com, 34114 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
> 
> We'd still need code to serialize frames. And for what? What would we get with this scheme?

Smoother transition, perhaps?

Anyway, I've compared the values of some important members of 'struct
frame' after restoring from pdump, and didn't see any other problems.
So Karl, could you please try the patch below, which is based on your
idea, but with a quirk?

And before you apply the patch, could you perhaps show C and Lisp
backtraces from the errors you were seeing?  I don't see those errors
here when I try your recipe, and I'd like to better understand where
the problem happens.

Thanks.

diff --git a/src/dispnew.c b/src/dispnew.c
index 88783cd..1cafe29 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6037,7 +6037,18 @@ init_display_interactive (void)
      except on Windows, where we at least want to initialize it.  */
 #ifndef WINDOWSNT
   if (IS_DAEMON)
+    {
+      /* Pdump'ed Emacs doesn't record the initial frame from temacs,
+	 so the non-basic faces realized for that frame in temacs
+	 aren't in emacs.  This causes errors when users try to
+	 customize those faces in their init file.  The call to
+	 init_faces_initial will realize these faces now.  (Non-daemon
+	 Emacs does this either near the end of this function or when
+	 the GUI frame is created.)  */
+      if (dumped_with_pdumper_p ())
+        init_faces_initial ();
       return;
+    }
 #endif
 
   /* If the user wants to use a window system, we shouldn't bother

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

From: Karl Otness <karl <at> karlotness.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34114 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>,
 Kaushal Modi <kaushal.modi <at> gmail.com>
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Thu, 24 Jan 2019 19:22:34 +0000

On Thu, Jan 24, 2019 at 3:12 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> So Karl, could you please try the patch below, which is based on your
> idea, but with a quirk?

That patch seems to fix the issue for me. Thanks for taking a look at it.

> And before you apply the patch, could you perhaps show C and Lisp
> backtraces from the errors you were seeing?  I don't see those errors
> here when I try your recipe, and I'd like to better understand where
> the problem happens.

As far as backtraces, here's the output I get when running with my init
file containing just "(toggle-debug-on-error)" and "(load-theme 'wombat t)":

> Error: (error (error "Invalid face" tooltip))
>   (internal-get-lisp-face-attribute tooltip :family #<frame F1 0x56357368b9f0>)
>   (face-attribute tooltip :family #<frame F1 0x56357368b9f0>)
>   (face-attr-match-p tooltip (:inherit variable-pitch) #<frame F1 0x56357368b9f0>)
>   (frame-set-background-mode #<frame F1 0x56357368b9f0>)
>   (modify-frame-parameters nil ((menu-bar-lines . 1) (buried-buffer-list) (buffer-list #<buffer *scratch*>) (unsplittable) (modeline . t) (width . 10) (height . 9) (font . "tty") (background-color . "unspecified-bg") (foreground-color . "unspecified-fg")))
>   (frame-notice-user-settings)
>   (#[0 "\11\203\10\0\306\11!\21\n\2042\0\13\2032\0\f\307\267\202'\0\310\311\13!\312\"\210\313\314\13!!\315P\2021\0\314\316\317\13\320 \321 $!\22\15\204;\0\322\323\324\"\210\16!\204Q\0\16\"\203Q\0\16#\204Q\0\16\"\325=\203t\0\16$\300=\204`\0\326\327\330\331\332 $\210\333\334!\203i\0\334 \210\333\335!\203t\0\335\336 !\210\333\337!\203}\0\337 \210\15?\205\205\0\322\340!\207" [(("-cdac$" . 1.3)) default-directory auto-save-list-file-name auto-save-list-file-prefix system-type inhibit-startup-hooks abbreviate-file-name #s(hash-table size 1 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ms-dos 22)) make-directory file-name-directory t make-temp-name expand-file-name "~" format "%s%d-%s~" emacs-pid system-name run-hooks emacs-startup-hook term-setup-hook pc set-face-attribute default nil :font font-spec fboundp frame-notice-user-settings frame-set-background-mode selected-frame font-menu-add-default window-setup-hook frame-initial-frame initial-window-system noninteractive face-font-rescale-alist] 6])
>   (normal-top-level)

The C backtrace is mostly just funcalls, but this is what I get from a
breakpoint at xfaces.c:1866 which I think is where the actual error is
signaled.

> #0  0x00005555556b2764 in lface_from_face_name_no_resolve (f=0x555555e76a30, face_name=..., signal_p=true) at xfaces.c:1866
> #1  0x00005555556b27cb in lface_from_face_name (f=0x555555e76a30, face_name=..., signal_p=true) at xfaces.c:1884
> #2  0x00005555556b7acd in Finternal_get_lisp_face_attribute (symbol=..., keyword=..., frame=...) at xfaces.c:3731
> #3  0x00005555557e9df7 in funcall_subr (subr=0x555555d6e7e0 <Sinternal_get_lisp_face_attribute>, numargs=3, args=0x7fffffffbe10) at eval.c:2940
> #4  0x00005555557e98b7 in Ffuncall (nargs=4, args=0x7fffffffbe08) at eval.c:2860
> #5  0x000055555583e47d in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=3, args=0x7fffffffc328) at bytecode.c:633
> #6  0x00005555557ea4e7 in funcall_lambda (fun=..., nargs=3, arg_vector=0x7fffffffc310) at eval.c:3058
> #7  0x00005555557e98fb in Ffuncall (nargs=4, args=0x7fffffffc308) at eval.c:2862
> #8  0x000055555583e47d in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=3, args=0x7fffffffc890) at bytecode.c:633
> #9  0x00005555557ea4e7 in funcall_lambda (fun=..., nargs=3, arg_vector=0x7fffffffc878) at eval.c:3058
> #10 0x00005555557e98fb in Ffuncall (nargs=4, args=0x7fffffffc870) at eval.c:2862
> #11 0x000055555583e47d in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffffffce00) at bytecode.c:633
> #12 0x00005555557ea4e7 in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffffffcdf8) at eval.c:3058
> #13 0x00005555557e98fb in Ffuncall (nargs=2, args=0x7fffffffcdf0) at eval.c:2862
> #14 0x00005555557e90ab in call1 (fn=..., arg1=...) at eval.c:2711
> #15 0x00005555556b70b9 in update_face_from_frame_parameter (f=0x555555e76a30, param=..., new_value=...) at xfaces.c:3398
> #16 0x00005555555abead in Fmodify_frame_parameters (frame=..., alist=...) at frame.c:3236
> #17 0x00005555557e9dcb in funcall_subr (subr=0x555555d69ea0 <Smodify_frame_parameters>, numargs=2, args=0x7fffffffd0d8) at eval.c:2937
> #18 0x00005555557e98b7 in Ffuncall (nargs=3, args=0x7fffffffd0d0) at eval.c:2860
> #19 0x000055555583e47d in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffd820) at bytecode.c:633
> #20 0x00005555557ea4e7 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffd820) at eval.c:3058
> #21 0x00005555557e98fb in Ffuncall (nargs=1, args=0x7fffffffd818) at eval.c:2862
> #22 0x000055555583e47d in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffdd00) at bytecode.c:633
> #23 0x00005555557ea4e7 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffdd00) at eval.c:3058
> #24 0x00005555557e98fb in Ffuncall (nargs=1, args=0x7fffffffdcf8) at eval.c:2862
> #25 0x000055555583d4f1 in bcall0 (f=...) at bytecode.c:328
> #26 0x00005555557ebb26 in do_one_unbind (this_binding=0x7fffffffdd80, unwinding=true, bindflag=SET_INTERNAL_UNBIND) at eval.c:3504
> #27 0x00005555557ebfea in unbind_to (count=5, value=...) at eval.c:3631
> #28 0x000055555583e566 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffe3b0) at bytecode.c:653
> #29 0x00005555557ea4e7 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffe3b0) at eval.c:3058
> #30 0x00005555557ea152 in apply_lambda (fun=..., args=..., count=4) at eval.c:2994
> #31 0x00005555557e812f in eval_sub (form=...) at eval.c:2373
> #32 0x00005555557e7428 in Feval (form=..., lexical=...) at eval.c:2147
> #33 0x000055555571afd4 in top_level_2 () at keyboard.c:1099
> #34 0x00005555557e5427 in internal_condition_case (bfun=0x55555571afb1 <top_level_2>, handlers=..., hfun=0x55555571a9a7 <cmd_error>) at eval.c:1376
> #35 0x000055555571b01c in top_level_1 (ignore=...) at keyboard.c:1107
> #36 0x00005555557e488c in internal_catch (tag=..., func=0x55555571afd6 <top_level_1>, arg=...) at eval.c:1139
> #37 0x000055555571aefb in command_loop () at keyboard.c:1068
> #38 0x000055555571a48e in recursive_edit_1 () at keyboard.c:714
> #39 0x000055555571a686 in Frecursive_edit () at keyboard.c:785
> #40 0x0000555555718244 in main (argc=2, argv=0x7fffffffe8c8) at emacs.c:1902

Thanks again,
Karl

Message #64 received at 34114-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Karl Otness <karl <at> karlotness.com>
Cc: 34114-done <at> debbugs.gnu.org, dancol <at> dancol.org, kaushal.modi <at> gmail.com
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Sat, 26 Jan 2019 12:22:16 +0200

> From: Karl Otness <karl <at> karlotness.com>
> Date: Thu, 24 Jan 2019 19:22:34 +0000
> Cc: Daniel Colascione <dancol <at> dancol.org>, 34114 <at> debbugs.gnu.org, 
> 	Kaushal Modi <kaushal.modi <at> gmail.com>
> 
> On Thu, Jan 24, 2019 at 3:12 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > So Karl, could you please try the patch below, which is based on your
> > idea, but with a quirk?
> 
> That patch seems to fix the issue for me. Thanks for taking a look at it.

Thanks, I installed it now.

> > And before you apply the patch, could you perhaps show C and Lisp
> > backtraces from the errors you were seeing?  I don't see those errors
> > here when I try your recipe, and I'd like to better understand where
> > the problem happens.
> 
> As far as backtraces, here's the output I get when running with my init
> file containing just "(toggle-debug-on-error)" and "(load-theme 'wombat t)":

Thanks for this and the C backtrace, I think I understand now what was
the problem.

Message #67 received at 34114-done <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34114-done <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>,
 Karl Otness <karl <at> karlotness.com>
Subject: Re: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Sun, 27 Jan 2019 13:40:22 -0500

[Message part 1 (text/plain, inline)]

On Sat, Jan 26, 2019 at 5:22 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

>
> Thanks, I installed it now.
>

Thanks everyone!

I updated Emacs from master and now my theme loads fine with the default
pdumper option enabled.

[Message part 2 (text/html, inline)]

Previous Next

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