summaryrefslogtreecommitdiff
path: root/lisp/emacs-lisp/ert-x.el
diff options
context:
space:
mode:
authorJoão Távora <joaotavora@gmail.com>2022-12-15 15:26:13 +0000
committerJoão Távora <joaotavora@gmail.com>2022-12-16 08:53:10 +0000
commit8bf4cdcf79bc3254a9169f28f68922ab83bd4e78 (patch)
tree57f6f26873857115ea80828b58d8aa0e10ed8630 /lisp/emacs-lisp/ert-x.el
parent033071692c7cd1cd550d25170d4b3168668567ac (diff)
downloademacs-8bf4cdcf79bc3254a9169f28f68922ab83bd4e78.tar.gz
emacs-8bf4cdcf79bc3254a9169f28f68922ab83bd4e78.tar.bz2
emacs-8bf4cdcf79bc3254a9169f28f68922ab83bd4e78.zip
Avoid recursive process filters in lisp/jsonrpc.el (bug#60088)
jsonrpc.el may lose JSON-RPC messages because of recursive process filters. The problem happens in jsonrpc.el's jsonrpc--process-filter. The code of the process filter didn't expect to be called recursively and fails in that case. But that can happen if the three conditions are verified. 1. the client code invoked by its jsonrpc--connection-receive inside the process filter callee immediately sends follow-up input to process within the same Lisp stack. This is a common scenario, especially during LSP initialiation sequence used by Eglot, a jsonrpc.el client. 2. that follow-up message is large enough for process-send-string to send the input in bunches (output from processes can arrive in between bunches). 3. the process happens to have already some more output ready The fix in this commit detects recursive invocations and immediately re-schedules them as non-recursive calls to the jsonrpc--process-filter (but started from timers). * lisp/jsonrpc.el (jsonrpc--process-filter): Rework. (Version): Bump to 1.0.16.
Diffstat (limited to 'lisp/emacs-lisp/ert-x.el')
0 files changed, 0 insertions, 0 deletions