I have a certain Lisp file that appears to be toxic to the emacs/slime combination. If I edit the file while slime is running (by which I just mean there is a slime-repl buffer with an active lisp in it), emacs crashes. If I edit the same file without slime being active, or edit another lisp file in slime's presence, no crash. Also, I get no crash if emacs runs in a terminal.
I should mention that the file in question contains some nonstandard lisp syntax. I have a reader macro that reads in something like @2006-12-03 and converts it to a date. But of course, this is harmless if read with standard syntax: It just becomes another symbol.
I am somewhat at a loss as to how I can get enough information out of the crash so as to gain some notion about why and how this happens.
A bit of background: The slime is from cvs, downloaded in the past few days. The lisp is sbcl 1.0. I am running GNU Emacs 23.0.0, the emacs-unicode-2 branch out of cvs (somewhat stale) on Mac OS X 10.4.8.
If I start sbcl in a terminal window, run (swank:create-server :dont-close) and the connect from slime and trigger the bug, this is what I see in the terminal
;; swank:close-connection: end of file on #<sb-sys:fd-stream for "a constant string" {11CFA201}>
which I suppose is the expected result if emacs just goes away for any reason.
The crash leaves a backtrace in Library/Logs/CrashReporter/emacs.crash.log which could actually be informative, since my emacs is not stripped. I include it below, in case anybody can make sense out of it. But the following excerpt makes me wonder if it is really some incoming data from the superior lisp that is causing the trouble?
37 emacs 0x0015e68c read_process_output + 1236 (process.c:5088) 38 emacs 0x00160fd4 wait_reading_process_output + 4200 (process.c:4697) 39 emacs 0x0000bcd0 sit_for + 216 (dispnew.c:6412) 40 emacs 0x000be990 read_char + 3016 (keyboard.c:2777) 41 emacs 0x000c1b18 read_key_sequence + 2440 (keyboard.c:8872) 42 emacs 0x000c3768 command_loop_1 + 1064 (keyboard.c:1540)
Is there an easy way to get a trace of the traffic between emacs and the superior lisp? I know that some such information is traced on the emacs side, but since emacs crashes, I cannot see it there.
- Harald
---------------------------------------------------------------- PS. Sorry, but I won't include the toxic file, as it contains information of a private nature.
Anyway, here is the full backtrace.
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0110afff
Thread 0 Crashed: 0 emacs 0x00145934 char_quoted + 120 (syntax.c:301) 1 emacs 0x0014ae84 Fbackward_prefix_chars + 604 (syntax.c:2868) 2 emacs 0x00125d8c Ffuncall + 844 (eval.c:2898) 3 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 4 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 5 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 6 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 7 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 8 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 9 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 10 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 11 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 12 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 13 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 14 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 15 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 16 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 17 emacs 0x001259d4 apply_lambda + 248 (eval.c:3013) 18 emacs 0x00125198 Feval + 1312 (eval.c:2283) 19 emacs 0x0012553c Fprogn + 60 (eval.c:432) 20 emacs 0x00128010 Flet + 504 (eval.c:1053) 21 emacs 0x00125280 Feval + 1544 (eval.c:2306) 22 emacs 0x0012553c Fprogn + 60 (eval.c:432) 23 emacs 0x00125888 funcall_lambda + 800 (eval.c:3081) 24 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 25 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 26 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 27 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 28 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 29 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 30 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 31 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 32 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 33 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 34 emacs 0x00127848 Fapply + 532 (eval.c:2394) 35 emacs 0x001278b4 apply1 + 88 (eval.c:2659) 36 emacs 0x001237ec internal_condition_case_1 + 352 (eval.c:1522) 37 emacs 0x0015e68c read_process_output + 1236 (process.c:5088) 38 emacs 0x00160fd4 wait_reading_process_output + 4200 (process.c:4697) 39 emacs 0x0000bcd0 sit_for + 216 (dispnew.c:6412) 40 emacs 0x000be990 read_char + 3016 (keyboard.c:2777) 41 emacs 0x000c1b18 read_key_sequence + 2440 (keyboard.c:8872) 42 emacs 0x000c3768 command_loop_1 + 1064 (keyboard.c:1540) 43 emacs 0x00123aec internal_condition_case + 344 (eval.c:1474) 44 emacs 0x000b538c command_loop_2 + 64 (keyboard.c:1329) 45 emacs 0x00123660 internal_catch + 256 (eval.c:1211) 46 emacs 0x000b5078 command_loop + 148 (keyboard.c:1311) 47 emacs 0x000b5190 recursive_edit_1 + 176 (keyboard.c:1001) 48 emacs 0x000b5308 Frecursive_edit + 256 (keyboard.c:1063) 49 emacs 0x000b4ba8 main + 4496 (emacs.c:1800) 50 emacs 0x000024d0 _start + 348 (crt.c:272) 51 emacs 0x00002370 start + 60
Harald Hanche-Olsen hanche@math.ntnu.no writes:
I should mention that the file in question contains some nonstandard lisp syntax. I have a reader macro that reads in something like @2006-12-03 and converts it to a date. But of course, this is harmless if read with standard syntax: It just becomes another symbol.
If you remove the read-macro, do things still break? (Not in the sense of removing @2006-12-03 strings, but in the sense of removing the read-macro itself.)
I'm not suggesting this as a workaround, just to narrow things down a bit.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
+ Nikodemus Siivola nikodemus@random-state.net:
| Harald Hanche-Olsen hanche@math.ntnu.no writes: | | > I should mention that the file in question contains some nonstandard | > lisp syntax. I have a reader macro that reads in something like | > @2006-12-03 and converts it to a date. But of course, this is | > harmless if read with standard syntax: It just becomes another symbol. | | If you remove the read-macro, do things still break? (Not in the sense | of removing @2006-12-03 strings, but in the sense of removing the | read-macro itself.)
Yes. To be more precise, it happens whether or not I have loaded the file that defines the read-macro (it's in a different file than the toxic one).
I notice also that I could be more precise about what I mean by editing the file: Just visiting it is harmless. It is only when I start modifying it that the crash happens. It seems to be independent of the actual location within the file. (And the full pathname to the file contains only ASCII characters, in case that matters. Oh, and the file is latin-1 encoded, though I am using UTF-8 in my slime setup. It is of course read using :external-format :latin1 when my own programs open it for reading.)
- Harald
One more thing. I guess I should have asked this very basic question first: Does the mere fact of editing a Lisp file cause communication with the swank server? If so, what is being communicated?
- Harald
* Harald Hanche-Olsen [2006-12-03 23:05+0100] writes:
Is there an easy way to get a trace of the traffic between emacs and the superior lisp? I know that some such information is traced on the emacs side, but since emacs crashes, I cannot see it there.
You can set swank:*log-events* and you probably also want to disable swank:*global-debugger*. And there's always ethereal (or whatever it's called now).
* Harald Hanche-Olsen [2006-12-04 11:49+0100] writes:
One more thing. I guess I should have asked this very basic question first: Does the mere fact of editing a Lisp file cause communication with the swank server? If so, what is being communicated?
Yes, Emacs notifies the Lisp side on the first buffer change. There's also a lot of communication for arglist lookup and -- if enabled -- the autodoc stuff.
Helmut.
+ Helmut Eller heller@common-lisp.net:
| * Harald Hanche-Olsen [2006-12-03 23:05+0100] writes: | | > Is there an easy way to get a trace of the traffic between emacs and | > the superior lisp? I know that some such information is traced on the | > emacs side, but since emacs crashes, I cannot see it there. | | You can set swank:*log-events*
Ah. Obvious once you know what to look for. 8-) Thanks.
| > One more thing. I guess I should have asked this very basic question | > first: Does the mere fact of editing a Lisp file cause communication | > with the swank server? If so, what is being communicated? | | Yes, Emacs notifies the Lisp side on the first buffer change.
And not only that, but it gets the entire contents of the file back, which seems like a waste of bandwidth, given that slime doesn't appear to use the return value for anything.
The following patchlet simplifies the return value to nil or t, and incidentally stops my crashes from happening (however, the crashes are most likely a symptom of a deeper problem that I still don't know how to debug).
diff -u -8 -r1.6 swank-source-file-cache.lisp --- swank-source-file-cache.lisp 26 Nov 2006 18:08:30 -0000 1.6 +++ swank-source-file-cache.lisp 7 Dec 2006 21:07:35 -0000 @@ -39,17 +39,18 @@ text date)
(defimplementation buffer-first-change (filename) "Load a file into the cache when the user modifies its buffer. This is a win if the user then saves the file and tries to M-. into it." (unless (or (source-cached-p filename) (not (ignore-errors (probe-file filename)))) (ignore-errors - (source-cache-get filename (file-write-date filename))))) + (source-cache-get filename (file-write-date filename))) + t))
(defun get-source-code (filename code-date) "Return the source code for FILENAME as written on DATE in a string. If the exact version cannot be found then return the current one from disk." (or (source-cache-get filename code-date) (read-file filename)))
(defun source-cache-get (filename date)
- Harald
-
Harald Hanche-Olsen -
Helmut Eller -
Nikodemus Siivola