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