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