Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lost connection due to large arrays #803

Open
3b opened this issue Dec 6, 2023 · 0 comments
Open

Lost connection due to large arrays #803

3b opened this issue Dec 6, 2023 · 0 comments

Comments

@3b
Copy link
Contributor

3b commented Dec 6, 2023

Not sure exactly what i do to trigger it, but i frequently get dropped connections with following in *inferior-lisp* (after many minutes printing the contents of a large 3d array.)

;;; contents of large array skipped

encode-message
decode-message
decode-message
close-connection: The value 142340008 is not of type (UNSIGNED-BYTE 24) when binding COMMON-LISP:LENGTH ...
;; Event history end.
;; Backtrace:
0: (SWANK/RPC::WRITE-HEADER #<SB-SYS:FD-STREAM for "socket 127.0.0.1:57477, peer: 127.0.0.1:57480" {10082782C3}> 142340008) [external]
1: (SWANK/RPC:WRITE-MESSAGE (:RETURN (:OK "=> #3A(((-2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 ..)
2: (SWANK::ENCODE-MESSAGE (:RETURN (:OK "=> #3A(((-2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 -2000 ..)
3: (SWANK::DISPATCH-LOOP #<SWANK::MULTITHREADED-CONNECTION {1008278753}>)
4: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
5: ((FLET "WITHOUT-INTERRUPTS-BODY-156" :IN SB-THREAD::RUN))
6: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
7: ((FLET "WITHOUT-INTERRUPTS-BODY-149" :IN SB-THREAD::RUN))
8: (SB-THREAD::RUN)
9: ("foreign function: #x14003E885")
10: ("foreign function: #x14000A10A")
;; Connection to Emacs lost. [
;;  condition: The value
  142340008
is not of type
  (UNSIGNED-BYTE 24)
when binding LENGTH
;;  type: SWANK::SWANK-ERROR
;;  style: :SPAWN]

I suspect unsigned-byte 24 is a reasonable limitation for most of these cases, so truncating the output to fit in that limit would be better than just closing the connection with an error. (Sending the entire thing might be slightly better than the current error, but if it still takes 5-10min or more to transfer it would still be pretty annoying, so I don't think that would be better than truncating. )

Possibly some more things should be making sure *print-length* and similar have reasonable values as well, since I don't really need anywhere 16MB of output in the minibuffer. (Probably C-M-x in my case.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant