Subject: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer

From: João Távora <[email-masked]>
Date: Tue, 08 Dec 2020 15:56:49 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: João Távora <[email-masked]>
>> Date: Tue, 08 Dec 2020 11:44:39 +0000
>> 
>> When using SLY Common Lisp IDE package for Emacs, a user has recently
>> reported a strange intermittent error in SLY's asynchronous ElDoc
>> function.  That function produces documenttion by querying a network
>> process, a common technique in many such IDEs.  The user found that when
>> reducing eldoc-idle-delay to 0.1 he could trigger the problem more
>> often.
>> 
>> The original report lives at
>> https://github.com/joaotavora/sly/issues/385.
>> 
>> It was triggered with Emacs 27.1, but I have also reproduced it with a
>> recent master build.
>> 
>> After analysing the problem, I came to the conclusion that given certain
>> mysterious conditions, process-send-string, which is called from SLY's
>> `eldoc-documentation-function` will abruptly return non-locally even
>> though no error or quit seems to have been signalled.
>
> Can you elaborate on the evidence you found of this non-local exit?

It was evidenced by M-x trace-function process-send-string RET and also
by substituting the snippet I posted earlier with:

    (unwind-protect
       (progn
         (sly-send `(:emacs-rex ,form ,package ,thread ,id ,@extra-options))
         (setq send-success t))
     (if send-success
         (push (cons id continuation) (sly-rex-continuations))
       (sly-message
        "[issue#385] likely `process-send-string' exited non-locally from timer.")
       (sly-log-event `(:issue-385-sly-send-fishiness :id ,id
                                                      :form
                                                      ,form )
                      sly-dispatching-connection)))

Once in a while, the else branch of the if triggered.

Anyway, here's an observation:

    1 -> (process-send-string #<process sly-1> "00044d(:emacs-rex
    (slynk:autodoc (quote (\"defpackage\" \":slynk\" (\":use\" \":cl\"
    \":slynk-backend\" \":slynk-match\" \":slynk-rpc\") (\":export\"
    \"#:startup-multiprocessing\" \"#:start-server\" \"#:create-server\"
    \"#:stop-server\" \"#:restart-server\" \"#:ed-in-emacs\"
    \"#:inspect-in-emacs\" \"#:print-indentation-lossage\"
    \"#:invoke-sly-debugger\" \"#:slynk-debugger-hook\" \"#:emacs-inspect\"
    \"#:authenticate-client\" \"#:*loopback-interface*\"
    \"#:*buffer-readtable*\" \"#:process-requests\") (\":export\"
    \"#:*communication-style*\" \"#:*dont-close*\"
    \"#:*fasl-pathname-function*\" \"#:*log-events*\" \"#:*log-output*\"
    \"#:*configure-emacs-indentation*\" \"#:*readtable-alist*\"
    \"#:*global-debugger*\" \"#:*sly-db-quit-restart*\"
    \"#:*backtrace-printer-bindings*\"
    \"#:*default-worker-thread-bindings*\"
    \"#:*macroexpand-printer-bindings*\" \"#:*slynk-pprint-bindings*\"
    \"#:*string-elision-length*\" \"#:*inspector-verbose*\"
    \"#:*require-module*\" \"#:*eval-for-emacs-wrappers*\"
    \"#:*debugger-extra-options*\" \"#:*globally-redirect-io*\"
    \"#:*use-dedicated-output-stream*\" \"#:*dedicated-output-stream-port*\"
    slynk::%cursor-marker%))) :print-right-margin 80) \":slynk\" t 100) ") 1
    <- process-send-string: !non-local\ exit!

This was was pretty long, but it can be slower.  Also it was after 100
successful similar calls.

> And does "no error or quit" mean there's no trace of anything abnormal
> in the *Messages* buffer?

Yes, exactly.

> One possible reason for non-local exit, besides signaling an error, is
> stack overflow, although your description doesn't seem to indicate
> that this is probable.

Indeed.

> One other piece of information that could be relevant is that when
> Emacs calls the timer function, it sets inhibit-quit non-nil.

Right, and I added a formatting of quit-flag to the message
call I showed earlier and it came out nil.

   [sly] [issue#385] likely `process-send-string' exited non-locally from timer, also quit-flag = nil.

João