This came up a good while back, but as it's only bitten me today
after an upgrade, I thought I'd mention it:
if you are having problems with cl-sdl opengl and you are using the nvidia
linux opengl drivers, it might well be because of issues with the
TLS-enabled [TLS -> Thread Local Storage] [1] libraries in the driver.
You can persuade the nvidia driver to fallback to non-TLS libraries with an
env var as documented in the driver README:
export LD_ASSUME_KERNEL=2.3.98
Note that this has to be in the environment of the lisp process,
and therefore if you're running your lisp as an inferior process of
emacs, you might need to fiddle a bit to get it into the inferior
processes' environment.
I have little idea what it would take to get the TLS libraries working with
CMUCL (or SBCL with its native threading), but I'm going to guess it's
scary.
[1] http://people.redhat.com/drepper/tls.pdf
David Golden <············@oceanfree.net> writes:
> This came up a good while back, but as it's only bitten me today
> after an upgrade, I thought I'd mention it:
>
> if you are having problems with cl-sdl opengl and you are using the nvidia
> linux opengl drivers, it might well be because of issues with the
> TLS-enabled [TLS -> Thread Local Storage] [1] libraries in the driver.
Which upgrade?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> David Golden <············@oceanfree.net> writes:
>
>> This came up a good while back, but as it's only bitten me today
>> after an upgrade, I thought I'd mention it:
>
> Which upgrade?
>
Sorry, an actual hardware upgrade to an nvidia graphics card - meant I tried
the nvidia linux opengl drivers, though I don't like having binary-only
stuff on my system very much.
David Golden wrote:
>
> Note that this has to be in the environment of the lisp process,
> and therefore if you're running your lisp as an inferior process of
> emacs, you might need to fiddle a bit to get it into the inferior
> processes' environment.
>
Argh!
If you're running under SLIME on CMUCL rather than raw emacs
run-lisp I initially tested in, it doesn't work anyway, even with
LD_ASSUME_KERNEL in the environment. Uh oh. And beyond my ability to
really debug - Something very awry, to do with signals.
*Workaround:
Switch SLIME/SWANK communication style away from :SIGIO
(see Luke Gorrie's nice SLIME manual):
Place the following in ~/.swank.lisp:
(defparameter swank:*communication-style* :spawn)
I have described workaround on http://www.cliki.net/SLIME Tips.
*Notes:
This only happens when you try and run the sdl-opengl demos from the slime
repl - even with slime loaded, entering the following in the *inferior-lisp*
buffer slime uses doesn't trigger the problem.
(asdf:operate 'asdf:load-op :sdl-demos)
(nehe:run-tutorial 9)
See swank-cmucl.lisp in SLIME sources:
;;; In CMUCL we support all communication styles. By default we use
;;; `:SIGIO' because it is the most responsive, but it's somewhat
;;; dangerous: CMUCL is not in general "signal safe", and you don't
;;; know for sure what you'll be interrupting. Both `:FD-HANDLER' and
;;; `:SPAWN' are reasonable alternatives.
*Symptoms:
In the inferior lisp buffer behind slime:
-8<--------
*** Sigsegv in page not marked as write protected
{repeated several thousand times}
Error in function UNIX::SIGILL-HANDLER: Illegal Instruction at #x4017810D.
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(UNIX::SIGILL-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
#x3FFFC228))
Source:
; File: target:code/signal.lisp
(DEFINE-SIGNAL-HANDLER SIGILL-HANDLER "Illegal Instruction")
0]
-8<---------