How can I rethrow an error after recording a backtrace?

How can I rethrow an error after recording a backtrace?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 4249 bytes --]

Hey emacs-devel,

The Emacs server doesn't print backtraces, so I'm trying to get these backtraces myself and return them to the server.  After some exploration, I found about the debugger variable, and realized that I could actually force code to break into the debugger regardless of handlers using debug-on-signal. So far so good. Then I wrote the following "debugger"

    (defun my-handle-error (&rest args)
      (let (;; Prevent recursive error catching
            (debugger #'debug)
            (debug-on-quit nil)
            (debug-on-error nil)
            (debug-on-signal nil))
        (pcase args
          (`(exit ,retv) retv)
          (`(error ,error-args)
           (setq saved-backtrace (with-output-to-string (backtrace)))
           (signal (car error-args) (cdr error-args))))))

And then I called my code as follows:

    (let* (;; Make sure that we'll intercept all errors
           (debug-on-quit t)
           (debug-on-error t)
           (debug-on-signal t)
           (debug-ignored-errors nil)
           ;; Make sure debugger has room to execute
           (max-specpdl-size (+ 50 max-specpdl-size))
           (max-lisp-eval-depth (+ 50 max-lisp-eval-depth))
           ;; Register ourselves as the debugger
           (debugger #'my-handle-error))
      (my code here))

This was in part inspired by similar code in allout-widgets.el (although I think that code never worked, since it calls signal with a non-list second argument).

When running on an emacs server, though, this code doesn't work. That is, it works fine the first time, but not on further invocations; so I stepped through the code in GDB, and I understood that the issue was here:

    if (
        /* Don't try to run the debugger with interrupts blocked.
       The editing loop would return anyway.  */
        ! input_blocked_p ()
        && NILP (Vinhibit_debugger)
        /* Does user want to enter debugger for this kind of error?  */
        && (EQ (sig, Qquit)
        ? debug_on_quit
        : wants_debugger (Vdebug_on_error, conditions))
        && ! skip_debugger (conditions, combined_data)
        /* RMS: What's this for?  */
        && when_entered_debugger < num_nonmacro_input_events)
      {
        call_debugger (list2 (Qerror, combined_data));
        return 1;
      }

(in maybe_call_debugger). The first time around the debugger is called, but not the second time, because the `when_entered_debugger < num_nonmacro_input_events` is false (on the first round it evaluates to -1 < 0, and on the second one to 0 < 0). This reason for this clause was explained when this code was written back in 1991:

    /* The value of num_nonmacro_input_events as of the last time we
       started to enter the debugger.  If we decide to enter the debugger
       again when this is still equal to num_nonmacro_input_events, then we
       know that the debugger itself has an error, and we should just
       signal the error instead of entering an infinite loop of debugger
       invocations.  */

    static EMACS_INT when_entered_debugger;

The problem is that I'm running this code using emacsclient --eval '(error "abc")', and so the num_nonmacro_input_events value never increases. I "fixed" it this way:

    (defun my-handle-error (&rest args)
      (let (;; Prevent recursive error catching
            (debugger #'debug)
            (debug-on-quit nil)
            (debug-on-error nil)
            (debug-on-signal nil))
        ;; HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK ;;
        (setq num-nonmacro-input-events (1+ num-nonmacro-input-events))
        ;; HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK ;;
        (pcase args
          (`(exit ,retv) retv)
          (`(error ,error-args)
           (setq saved-backtrace (with-output-to-string (backtrace)))
           (signal (car error-args) (cdr error-args))))))

Is this going to have horrible consequences? If it is, could someone more experienced point me to how I am supposed to capture a backtrace and then rethrow an error? I can provide a full example if anyone wants to experiment and finds this description incomplete.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: How can I rethrow an error after recording a backtrace?

[Stefan Monnier]

>         (setq num-nonmacro-input-events (1+ num-nonmacro-input-events))

This should be in the server.el's process sentinel, so as to consider
emacsclient connections as "nonmacro input event".


        Stefan

Re: How can I rethrow an error after recording a backtrace?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 734 bytes --]

On 2016-08-04 22:23, Stefan Monnier wrote:
>>         (setq num-nonmacro-input-events (1+ num-nonmacro-input-events))
> 
> This should be in the server.el's process sentinel, so as to consider
> emacsclient connections as "nonmacro input event".

Hmm. Even with that, I'm not sure. Take the following (untested) program:

(condition-case err1 
    (condition-case err2
        (error "A")
      (error (error "B)))
  (error (message "Oups")))

Suppose I want to capture one backtrace for each of the signals in this program.  Assuming I register a debugger that re-throws all errors that it receives, won't the second error slip through, due to the nonmacro input event counter not having been increased?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: How can I rethrow an error after recording a backtrace?

[Stefan Monnier]

> Hmm. Even with that, I'm not sure. Take the following (untested) program:
>
> (condition-case err1 
>     (condition-case err2
>         (error "A")
>       (error (error "B)))
>   (error (message "Oups")))

This problem also affects the normal case (i.e. without server.el).

As I said elsewhere, I think this num-* side-condition can be dropped
because the inhibit-debugger variable should catch the same problems
but better.


        Stefan

Re: How can I rethrow an error after recording a backtrace?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Fri, 05 Aug 2016 22:11:55 -0400
> Cc: emacs-devel@gnu.org
> 
> As I said elsewhere, I think this num-* side-condition can be dropped
> because the inhibit-debugger variable should catch the same problems
> but better.

So maybe we should avoid entering the debugger only if _both_
variables say we shouldn't.  That would be safer than just tossing
num-nonmacro-input-events.

Re: How can I rethrow an error after recording a backtrace?

[Stefan Monnier]

> So maybe we should avoid entering the debugger only if _both_
> variables say we shouldn't.

That's what we do currently.


        Stefan

Re: How can I rethrow an error after recording a backtrace?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 5479 bytes --]

Some notes:

* I should really have asked "how can I capture multiple errors on Emacs server?". It turns out that the rethrowing is pretty irrelevant, as it just seems that the number of non-macro input events stays 0 on a --daemon server.

* In light of this, is this comment actually true?

  /* The value of num_nonmacro_input_events as of the last time we
     started to enter the debugger.  If we decide to enter the debugger
     again when this is still equal to num_nonmacro_input_events, then we
     know that the debugger itself has an error, and we should just
     signal the error instead of entering an infinite loop of debugger
     invocations.  */

  What if num_nonmacro_input_events just didn't increase because there were no such events? And thus, is the behavior that I'm seeing a bug? Or is it just a weird aspect of running code on a --daemon server, and I should submit a documentation patch suggesting to `(cl-incf num-nonmacro-input-events)'?

Cheers,
Clément.

On 2016-08-04 22:12, Clément Pit--Claudel wrote:
> Hey emacs-devel,
> 
> The Emacs server doesn't print backtraces, so I'm trying to get these backtraces myself and return them to the server.  After some exploration, I found about the debugger variable, and realized that I could actually force code to break into the debugger regardless of handlers using debug-on-signal. So far so good. Then I wrote the following "debugger"
> 
>     (defun my-handle-error (&rest args)
>       (let (;; Prevent recursive error catching
>             (debugger #'debug)
>             (debug-on-quit nil)
>             (debug-on-error nil)
>             (debug-on-signal nil))
>         (pcase args
>           (`(exit ,retv) retv)
>           (`(error ,error-args)
>            (setq saved-backtrace (with-output-to-string (backtrace)))
>            (signal (car error-args) (cdr error-args))))))
> 
> And then I called my code as follows:
> 
>     (let* (;; Make sure that we'll intercept all errors
>            (debug-on-quit t)
>            (debug-on-error t)
>            (debug-on-signal t)
>            (debug-ignored-errors nil)
>            ;; Make sure debugger has room to execute
>            (max-specpdl-size (+ 50 max-specpdl-size))
>            (max-lisp-eval-depth (+ 50 max-lisp-eval-depth))
>            ;; Register ourselves as the debugger
>            (debugger #'my-handle-error))
>       (my code here))
> 
> This was in part inspired by similar code in allout-widgets.el (although I think that code never worked, since it calls signal with a non-list second argument).
> 
> When running on an emacs server, though, this code doesn't work. That is, it works fine the first time, but not on further invocations; so I stepped through the code in GDB, and I understood that the issue was here:
> 
>     if (
>         /* Don't try to run the debugger with interrupts blocked.
>        The editing loop would return anyway.  */
>         ! input_blocked_p ()
>         && NILP (Vinhibit_debugger)
>         /* Does user want to enter debugger for this kind of error?  */
>         && (EQ (sig, Qquit)
>         ? debug_on_quit
>         : wants_debugger (Vdebug_on_error, conditions))
>         && ! skip_debugger (conditions, combined_data)
>         /* RMS: What's this for?  */
>         && when_entered_debugger < num_nonmacro_input_events)
>       {
>         call_debugger (list2 (Qerror, combined_data));
>         return 1;
>       }
> 
> (in maybe_call_debugger). The first time around the debugger is called, but not the second time, because the `when_entered_debugger < num_nonmacro_input_events` is false (on the first round it evaluates to -1 < 0, and on the second one to 0 < 0). This reason for this clause was explained when this code was written back in 1991:
> 
>     /* The value of num_nonmacro_input_events as of the last time we
>        started to enter the debugger.  If we decide to enter the debugger
>        again when this is still equal to num_nonmacro_input_events, then we
>        know that the debugger itself has an error, and we should just
>        signal the error instead of entering an infinite loop of debugger
>        invocations.  */
> 
>     static EMACS_INT when_entered_debugger;
> 
> The problem is that I'm running this code using emacsclient --eval '(error "abc")', and so the num_nonmacro_input_events value never increases. I "fixed" it this way:
> 
>     (defun my-handle-error (&rest args)
>       (let (;; Prevent recursive error catching
>             (debugger #'debug)
>             (debug-on-quit nil)
>             (debug-on-error nil)
>             (debug-on-signal nil))
>         ;; HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK ;;
>         (setq num-nonmacro-input-events (1+ num-nonmacro-input-events))
>         ;; HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK ;;
>         (pcase args
>           (`(exit ,retv) retv)
>           (`(error ,error-args)
>            (setq saved-backtrace (with-output-to-string (backtrace)))
>            (signal (car error-args) (cdr error-args))))))
> 
> Is this going to have horrible consequences? If it is, could someone more experienced point me to how I am supposed to capture a backtrace and then rethrow an error? I can provide a full example if anyone wants to experiment and finds this description incomplete.
> 
> Cheers,
> Clément.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: How can I rethrow an error after recording a backtrace?

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Thu, 4 Aug 2016 22:34:23 -0400
> 
> * I should really have asked "how can I capture multiple errors on Emacs server?". It turns out that the rethrowing is pretty irrelevant, as it just seems that the number of non-macro input events stays 0 on a --daemon server.

Only when invoking emacsclient to perform commands non-interactively,
right?  If you start an interactive session using emacsclient, the
debugger behaves as expected, right?

If so, the bug is that the daemon thinks it is in a situation
described by the comment you quote, while "emacs -batch" somehow
avoids that pitfall.  You should debug Emacs to understand why the
difference happens.

> * In light of this, is this comment actually true?
> 
>   /* The value of num_nonmacro_input_events as of the last time we
>      started to enter the debugger.  If we decide to enter the debugger
>      again when this is still equal to num_nonmacro_input_events, then we
>      know that the debugger itself has an error, and we should just
>      signal the error instead of entering an infinite loop of debugger
>      invocations.  */
> 
>   What if num_nonmacro_input_events just didn't increase because there were no such events? And thus, is the behavior that I'm seeing a bug?

Then how come "emacs -batch" doesn't exhibit the same behavior?

> Or is it just a weird aspect of running code on a --daemon server, and I should submit a documentation patch suggesting to `(cl-incf num-nonmacro-input-events)'?

No, I don't think so.

Re: How can I rethrow an error after recording a backtrace?

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Fri, 5 Aug 2016 03:20:17 -0400
> 
> > If so, the bug is that the daemon thinks it is in a situation 
> > described by the comment you quote, while "emacs -batch" somehow 
> > avoids that pitfall.  You should debug Emacs to understand why the 
> > difference happens.
> 
> Ok, I'll look into this.  But I need help in understanding exactly what I'm trying to track: with emacs -batch (without a daemon), there's only at most one entry into the debugger, right? That one is possible because the when_entered_debugger variable is initialized to -1, whereas the num_nonmacro_input_events counter is initialized to 0.

But with -daemon, even the first invocation of emacsclient already
doesn't display the backtrace, right?  So there's still something
different between these two use cases.

Re: How can I rethrow an error after recording a backtrace?

[Clément Pit--Claudel]

[-- Attachment #1.1.1: Type: text/plain, Size: 2757 bytes --]

On 2016-08-05 09:40, Eli Zaretskii wrote:
> But with -daemon, even the first invocation of emacsclient already 
> doesn't display the backtrace, right?  So there's still something 
> different between these two use cases.

Well, it depends what you mean by "display the backtrace": the server doesn't respect debug-on-error, but if I register my own debugger, then I *can* capture the first backtrace. I have attached a file cpc-server.el that will explain the issue better than I can explain it in words (thanks for your patience!). Here's how it's used:

    # Start a server, which offers one entry point cpc-eval
    # (cpc-eval form file) evals FORM, captures the output and a backtrace if any, and writes it to FILE
    $ emacs -Q -L . -l cpc-server --eval '(setq server-name "cpc")' --daemon
    (...)
    Starting Emacs daemon.

    # This should run (error "A"), record the backtrace, and save it to output-for-error-A
    $ emacsclient -s cpc --eval "(cpc-eval '(error \"A\") \"output-for-error-A\")"

    # Did it work? Yes: the *Messages* buffer shows that it did: the debugger was entered, and properly rethrew the error.
    $ emacsclient -s cpc --eval '(cpc-messages)' | xargs -0 printf
    Starting Emacs daemon.
    Going to eval (error "A") and write to "output-for-error-A"
    Debugger entered with args (error (error "A")) (1 times)
    Condition-case entered with error (error "A")
    Wrote /home/clement/.emacs.d/lisp/emacs-syntax-highlighter/example/server-issues/output-for-error-A

    # Just to confirm
    $ cat output-for-error-A
    (error (error "A") "  backtrace()
      (let ((standard-output standard-output)) (backtrace))
      (... long backtrace here; it works! ...)

    # Now let's throw a second error
    $ emacsclient -s cpc --eval "(cpc-eval '(error \"B\") \"output-for-error-B\")"

    # Did it work? No: the debugger isn't entered...
    $ emacsclient -s cpc --eval '(cpc-messages)' | xargs -0 printf
    Starting Emacs daemon.
    Going to eval (error "A") and write to "output-for-error-A"
    Debugger entered with args (error (error "A")) (1 times)
    Condition-case entered with error (error "A")
    Wrote /home/clement/.emacs.d/lisp/emacs-syntax-highlighter/example/server-issues/output-for-error-A
    Going to eval (error "B") and write to "output-for-error-B"
    Condition-case entered with error (error "B")
    Wrote /home/clement/.emacs.d/lisp/emacs-syntax-highlighter/example/server-issues/output-for-error-B

    # And indeed:
    $ cat output-for-error-B
    (error (error "B") nil)

If you uncomment the HACK HACK HACK line in cpc-server, then the second and subsequent invocations also work.

I hope this makes everything clear!
Clément.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: cpc-server.el --]
[-- Type: text/x-emacs-lisp; name="cpc-server.el", Size: 2686 bytes --]

(defvar cpc--backtrace nil
  "Backtrace of last error.")

(defvar cpc--debugger-entries-count 0
  "Backtrace of last error.")

(defun cpc--handle-error (&rest args)
  "Handle an error in code run on the server.
This function is appropriate as a value for `debugger' (hence
ARGS).  We need this function because the server doesn't print
backtraces; thus we take a more aggressive stand and simply
intercept all errors as they happen.  We just store the backtrace
in esh--server-backtrace and rethrow the error immediately; then
the `condition-case' in `cpc-eval' will catch the error,
unless it's nicely handled somewhere else."
  ;; Prevent recursive error catching
  (let ((debugger #'debug)
        (debug-on-quit nil)
        (debug-on-error nil)
        (debug-on-signal nil))
    ;; HACK HACK HACK: this makes everything work fine ;;;;;;;;;;;;;;;;;;
    ;; (setq num-nonmacro-input-events (1+ num-nonmacro-input-events)) ;;
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    (setq cpc--debugger-entries-count (1+ cpc--debugger-entries-count))
    (message "Debugger entered with args %S (%S times)" args cpc--debugger-entries-count)
    (pcase args
      (`(exit ,retv) retv)
      (`(error ,error-args)
       (setq cpc--backtrace (with-output-to-string (backtrace)))
       (signal (car error-args) (cdr error-args))))))

(defun cpc--writeout (file form)
  "Write FORM to FILE."
  (with-temp-buffer
    (insert (prin1-to-string form))
    (write-region (point-min) (point-max) file)))

(defun cpc-eval (form file)
  "Eval FORM and write result or error to FILE.
Written value can be `read' from FILE; it is either a
list (success RESULT) or a cons (error ERR BACKTRACE)."
  (message "Going to eval %S and write to %S" form file)
  (condition-case err
      (let* (;; Make sure that we'll intercept all errors
             (debug-on-quit t)
             (debug-on-error t)
             (debug-on-signal t)
             (debug-ignored-errors nil)
             ;; Make sure debugger has room to execute
             (max-specpdl-size (+ 50 max-specpdl-size))
             (max-lisp-eval-depth (+ 50 max-lisp-eval-depth))
             ;; Register ourselves as the debugger
             (debugger #'cpc--handle-error))
        (setq cpc--backtrace nil)
        (cpc--writeout file `(success ,(eval form))))
    (error (message "Condition-case entered with error %S" err)
           (cpc--writeout file `(error ,err ,cpc--backtrace)))))

(defun cpc-messages ()
  "Return contents of *Messages* buffer."
  (with-current-buffer "*Messages*" (buffer-string)))

(provide 'cpc)
;;; cpc.el ends here

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: How can I rethrow an error after recording a backtrace?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Fri, 5 Aug 2016 11:38:14 -0400
> 
> On 2016-08-05 09:40, Eli Zaretskii wrote:
> > But with -daemon, even the first invocation of emacsclient already 
> > doesn't display the backtrace, right?  So there's still something 
> > different between these two use cases.
> 
> Well, it depends what you mean by "display the backtrace": the server doesn't respect debug-on-error

Why doesn't it?  Isn't that already a bug?

> but if I register my own debugger, then I *can* capture the first backtrace. I have attached a file cpc-server.el that will explain the issue better than I can explain it in words (thanks for your patience!). Here's how it's used:

So you are saying that the problem is the daemon doesn't increment
num-nonmacro-input-events for each new connection?  That should be
easy enough to fix, isn't it?

Re: How can I rethrow an error after recording a backtrace?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]

On 2016-08-06 06:02, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit--Claudel <clement.pit@gmail.com>
>> Date: Fri, 5 Aug 2016 11:38:14 -0400
>>
>> On 2016-08-05 09:40, Eli Zaretskii wrote:
>>> But with -daemon, even the first invocation of emacsclient already 
>>> doesn't display the backtrace, right?  So there's still something 
>>> different between these two use cases.
>>
>> Well, it depends what you mean by "display the backtrace": the server doesn't respect debug-on-error
> 
> Why doesn't it?  Isn't that already a bug?

I think you confirmed that it was in the other "Backtraces on server?" thread?

>> but if I register my own debugger, then I *can* capture the first backtrace. I have attached a file cpc-server.el that will explain the issue better than I can explain it in words (thanks for your patience!). Here's how it's used:
> 
> So you are saying that the problem is the daemon doesn't increment
> num-nonmacro-input-events for each new connection?  That should be
> easy enough to fix, isn't it?

Yes, but I fear it wouldn't cover the following case:

(condition-case err1 
    (condition-case err2
        (error "A")
      (error (error "B)))
  (error (message "Oups")))

Only the first error would be captured by the debugger.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: How can I rethrow an error after recording a backtrace?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Sat, 6 Aug 2016 11:24:03 -0400
> 
> > So you are saying that the problem is the daemon doesn't increment
> > num-nonmacro-input-events for each new connection?  That should be
> > easy enough to fix, isn't it?
> 
> Yes, but I fear it wouldn't cover the following case:
> 
> (condition-case err1 
>     (condition-case err2
>         (error "A")
>       (error (error "B)))
>   (error (message "Oups")))
> 
> Only the first error would be captured by the debugger.

Which is a separate issue, as Stefan points out.  One issue at a time,
okay?

Re: How can I rethrow an error after recording a backtrace?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1046 bytes --]

On 2016-08-06 11:31, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit--Claudel <clement.pit@gmail.com>
>> Date: Sat, 6 Aug 2016 11:24:03 -0400
>>
>>> So you are saying that the problem is the daemon doesn't increment
>>> num-nonmacro-input-events for each new connection?  That should be
>>> easy enough to fix, isn't it?
>>
>> Yes, but I fear it wouldn't cover the following case:
>>
>> (condition-case err1 
>>     (condition-case err2
>>         (error "A")
>>       (error (error "B)))
>>   (error (message "Oups")))
>>
>> Only the first error would be captured by the debugger.
> 
> Which is a separate issue, as Stefan points out.  One issue at a time,
> okay?

Of course. It's not always trivial to tell what is an isn't an issue, let alone which ones are separate issues.  Especially with virtually no knowledge of Emacs internals. Sorry for introducing confusion.

Am I mistaken to think that a fix for that separate issue would solve the more specific issue with the daemon?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: How can I rethrow an error after recording a backtrace?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Sat, 6 Aug 2016 11:49:36 -0400
> 
> >> (condition-case err1 
> >>     (condition-case err2
> >>         (error "A")
> >>       (error (error "B)))
> >>   (error (message "Oups")))
> >>
> >> Only the first error would be captured by the debugger.
> > 
> > Which is a separate issue, as Stefan points out.  One issue at a time,
> > okay?
> 
> Of course. It's not always trivial to tell what is an isn't an issue, let alone which ones are separate issues.  Especially with virtually no knowledge of Emacs internals. Sorry for introducing confusion.
> 
> Am I mistaken to think that a fix for that separate issue would solve the more specific issue with the daemon?

Maybe so, but I'd like to solve the immediate issue at hand first,
without introducing backward-incompatible changes.