I am running cmu-lisp under Rh8.0 and Emacs21.2.1. I am experimenting
with the alien interface. When I run my alien C program from an X
terminal, I get the following reasonable response:
********************
* (hexagon-call::makehexagon "pic1.jpg")
Compiling LAMBDA (#:G925 #:G926):
Compiling Top-Level Form:
NIL
*
********************
However, when I run it from a lisp window process in Emacs, it fails to
work, stating the following:
********************
* (hexagon-call::makehexagon "pic2.jpg")
Compiling LAMBDA (#:G933 #:G934):
Compiling Top-Level Form:
Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at
#x41724817.
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(UNIX::SIGSEGV-HANDLER #<unused-arg>
#<unused-arg>
#.(SYSTEM:INT-SAP #x3FFFE8E0))
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer
exists:
target:code/signal.lisp.
0]
*******************
How come? It would be nice to use Emacs for this development. The
foreign function returns nothing, so I don't think that is the problem
for emacs. Any suggestions about what to look at?
thanks
Blake
From: Eric Marsden
Subject: Re: emacs inferior lisp process fails when same x terminal process doesn't
Date:
Message-ID: <wzivfrak6kv.fsf@melbourne.laas.fr>
>>>>> "bl" == blake <········@earthlink.net> writes:
bl> However, when I run it from a lisp window process in Emacs, it fails
bl> to work, stating the following:
bl> * (hexagon-call::makehexagon "pic2.jpg")
bl> Compiling LAMBDA (#:G933 #:G934):
bl> Compiling Top-Level Form:
bl> Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at
bl> #x41724817.
bl> How come? It would be nice to use Emacs for this development. The
bl> foreign function returns nothing, so I don't think that is the problem
bl> for emacs. Any suggestions about what to look at?
The only reason I can see for this is that your process environment
differs between Emacs and your shell. Compare the results of the "env"
command, and the value of EXT:*ENVIRONMENT-LIST* in CMUCL.
The SEGV is very likely coming from your foreign library scribbling
over CMUCL's address space, possibly because you have passed it an
invalid pointer.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>