segmentation fault after (room)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Invalid
|
Undecided
|
Unassigned |
Bug Description
I have connected to our production server using SLIME and typed (room) to repl, got this back:
TACTIX> (room)
Dynamic space usage is: 84,827,952 bytes.
Read-only space usage is: 3,488 bytes.
Static space usage is: 2,256 bytes.
Control stack usage is: 5,576 bytes.
Binding stack usage is: 472 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.
At that point SBCL crashed with segmentation fault. Unfortunately I can't provide a test case, it a huge system and I have no idea where/why/what crashes.
I have noticed big performance degradation on the server before this happened, with average events delays 15 ms, (such delays are expected when there are 20 games running at the same time on the server), there was just one at that time.
Also, I suspect there might be a memory leak (either in our application or in SBCL), since heap exhaustion errors happen pretty regularly after several hunders of finished games. This instance was previously under similar heavy load, but with almost no load when the crash happened.
tuser@tmachine32 ~ $ sbcl --version
SBCL 1.0.26-r1-gentoo
That's the version we use, but the application on the production server is as a Lisp executable image.
TACTIX> *features*
(:LTK :SPLIT-SEQUENCE :SBCL-USES-
:SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL :SB-SOURCE-
:STACK-
:STACK-
tuser@tmachine32 ~ $ uname -a
Linux tmachine32 2.6.18-
Please note that this is EC2 instance, so while the uname tells that it's dual core, we actually have just one core to our disposal. And, it runs in 32-bit mode (limitation of small instance) despite that Opteron is 64-bit.
Let me know whether there is something I can do to gather more useful informations to fix this please.
Thanks,
Karol Skocik
I have a test case to reproduce it quite reliably:
;; this is iota from alexandria
(defun iota (n &key (start 0) (step 1))
(declare (type (integer 0) n) (number start step))
(loop repeat n
for i = (+ start (- step step)) then (+ i step)
collect i))
(defun test-iota (n)
(make-array 100 :initial-contents (iota 100))))) make-thread #'thread-fn)))))
(flet ((thread-fn ()
(loop (sleep 0.01)
(loop :repeat n
:collect (sb-thread:
First, run (test-iota 10), then in repl:
(loop :repeat 100 :do (room))
What's interesting is that it does not crash without ":initial-contents (iota 100)" in make-array in thread-fn.
Karol