bug#34114: 27.0.50: pdumper and themes with Emacs daemon

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Karl Otness]

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

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 512 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 785 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Karl Otness]

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

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Daniel Colascione]

[-- Attachment #1: Type: text/html, Size: 65 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Karl Otness]

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@dancol.org> wrote:
>
> Looks reasonable to me. Want to install it?

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Daniel Colascione]

[-- Attachment #1: Type: text/html, Size: 90 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Karl Otness]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

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@dancol.org> wrote:
>
> Should fall under the de minimus exception to paperwork requirements

[-- Attachment #2: 0001-Initialize-faces-in-daemon-mode-with-pdumper-Bug-341.patch --]
[-- Type: text/x-patch, Size: 1171 bytes --]

From 6c85063851f83e51532013a354c0f1ce329d070a Mon Sep 17 00:00:00 2001
From: Karl Otness <karl@karlotness.com>
Date: Fri, 18 Jan 2019 23:56:44 +0000
Subject: [PATCH] Initialize faces in daemon mode with pdumper (Bug#34114)

* src/dispnew.c (init_display_interactive): Call init_faces_initial
in daemon mode.
---
 src/dispnew.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/dispnew.c b/src/dispnew.c
index 88783cd5da..226f4731cd 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6033,6 +6033,10 @@ init_display_interactive (void)
     }
 #endif /* SIGWINCH */
 
+  /* Set up faces of the initial terminal frame.  */
+  if (!noninteractive && NILP (Vinitial_window_system))
+    init_faces_initial ();
+
   /* If running as a daemon, no need to initialize any frames/terminal,
      except on Windows, where we at least want to initialize it.  */
 #ifndef WINDOWSNT
@@ -6176,10 +6180,6 @@ init_display_interactive (void)
   }
 
   calculate_costs (XFRAME (selected_frame));
-
-  /* Set up faces of the initial terminal frame.  */
-  if (!noninteractive && NILP (Vinitial_window_system))
-    init_faces_initial ();
 }
 
 void
-- 
2.20.1

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

> From: Karl Otness <karl@karlotness.com>
> Date: Fri, 18 Jan 2019 23:02:14 +0000
> Cc: Kaushal Modi <kaushal.modi@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.

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Daniel Colascione]

On 1/19/19 2:05 AM, Eli Zaretskii wrote:
>> From: Karl Otness <karl@karlotness.com>
>> Date: Fri, 18 Jan 2019 23:02:14 +0000
>> Cc: Kaushal Modi <kaushal.modi@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.

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

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

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


That was Karl :)

I am simply using unexec for now.

[-- Attachment #2: Type: text/html, Size: 525 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

> Cc: 34114@debbugs.gnu.org, kaushal.modi@gmail.com
> From: Daniel Colascione <dancol@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.

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Daniel Colascione]

On 1/22/19 8:45 AM, Eli Zaretskii wrote:
>> Cc: 34114@debbugs.gnu.org, kaushal.modi@gmail.com
>> From: Daniel Colascione <dancol@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.

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

> Cc: karl@karlotness.com, 34114@debbugs.gnu.org, kaushal.modi@gmail.com
> From: Daniel Colascione <dancol@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?

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Daniel Colascione]

[-- Attachment #1: Type: text/html, Size: 1482 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

On January 23, 2019 6:05:40 AM GMT+02:00, Daniel Colascione <dancol@dancol.org> wrote:
> 
> 
> 
> On Jan 22, 2019 7:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Cc: karl@karlotness.com, 34114@debbugs.gnu.org,
> kaushal.modi@gmail.com 
> > From: Daniel Colascione <dancol@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?

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Daniel Colascione]

[-- Attachment #1: Type: text/html, Size: 2200 bytes --]

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

> Date: Tue, 22 Jan 2019 22:48:59 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: karl@karlotness.com, 34114@debbugs.gnu.org, kaushal.modi@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

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Karl Otness]

On Thu, Jan 24, 2019 at 3:12 PM Eli Zaretskii <eliz@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

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Eli Zaretskii]

> From: Karl Otness <karl@karlotness.com>
> Date: Thu, 24 Jan 2019 19:22:34 +0000
> Cc: Daniel Colascione <dancol@dancol.org>, 34114@debbugs.gnu.org, 
> 	Kaushal Modi <kaushal.modi@gmail.com>
> 
> On Thu, Jan 24, 2019 at 3:12 PM Eli Zaretskii <eliz@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.

bug#34114: 27.0.50: pdumper and themes with Emacs daemon

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On Sat, Jan 26, 2019 at 5:22 AM Eli Zaretskii <eliz@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.

[-- Attachment #2: Type: text/html, Size: 544 bytes --]