Folks-- I'm the guy with the toy "cl-browser" app which embeds gecko in a gtk app. Some context: What I want to do is create a nice standalone version so people don't have to know implementation details and I therefor (if this goes forward) don't have to write documentation. What this means for me is that I'll create a shell script, save a core with the code in it, save a copy of the runtime, build an installable package, etc, etc, and then, in my script, do something like: /usr/lib/cl-browser/my-sbcl --core /usr/lib/cl-browser/my-core --eval '(browser:main)' So far so good. This kind of thing has worked well for me on other projects. The problem: Alas, but when I try this with sbcl 0.9.7 and cffi (12/30/2005), I get a segmentation fault. Is this because of some problems with CFFI, something inherent in SBCL and its memory model? Here's what happens. sbcl * (require 'browser) * (save-lisp-and-die "foo.core") % sbcl --core foo.core --eval '(browser:main)' ... my debug output printf stuff ... Segmentation fault And that's the end of the story. The browser appears momentarily, then goes away. As near as I can tell, this happens about the time I try connecting callbacks to signals defined in the glade file. On one test of tall this, I got: connecting glade signals <== my printf fatal error encountered in SBCL pid 8097(tid 3085362880): fault in heap page not marked as write-protected So, does this mean we can't save a core with CFFI in it? I know there are other ways I can simulate a standalone executable, but I was just wondering if we users should just take for granted we can't build a new core file (with sbcl, anyway), or is this just an ongoing problem yet to be fixed? Thanks, Keith