On Mon, Jul 29, 2002 at 11:22:04AM -0400, Raymond Toy wrote:
> >>>>> "Christophe" == Christophe Rhodes <csr21@...> writes:
> > So, I was getting ready to merge this into CVS, when a little voice said
> > "test it some more". So I decided to try to build it on my x86/Linux
> > laptop. All went swimmingly; it got through genesis; got through
> > cold-init, built PCL and dumped a core. Whereupon I decided to run the
> > tests; and my shiny new sbcl binary hung on startup, never getting into
> > lisp land.
> Don't know if this helps, but I did notice that in one of my attempts
> to make this all work on CMUCL, there were a few calls to
> make-sequence-like. However, the given sequence was a vector with a
> fill pointer and the length was less than the actual length of the
> vector. With these checks enabled, this causes a failure, of course.
> Don't remember what I did to fix this, if any.
I don't think it's this; I've got code in make-sequence-like to remove
the length information from the type of the sequence passed to it. It's
not a straightforward failure, either, sadly; I've now tested my patch
on more system, and (with the uncommenting of the CONCATENATE transform
for strings to compile away calls that are too difficult early in
cold-init, *sigh*) it works on sparc, alpha and ppc; it fails on x86.
This leads me to believe that, in fact, something is going wrong either
in gencgc or in purify. (Or, possibly, both; see below).
Let me elaborate a bit on the symptoms on the x86 (Linux, but I imagine
these to be the same on *BSD... maybe someone motivated could check?).
Compiling with :SB-SHOW, what happens is that cold-init and so on go
swimmingly, pcl is compiled, SAVE-LISP-AND-DIE happens, and things
appear to be fine. But running the resultant core (with
"src/runtime/sbcl --core output/sbcl.core", a pattern which is hardwired
into my fingers now) yields infinite SIGSEGVs; a little investigation
with gdb reveals that, at the crucial point in call_into_lisp
examination of the memory at $eax-1 shows a uniform sea of 0x0000000s,
so jumping to *($eax-1) obviously leads to death.
Compiling without :SB-SHOW, however, leads to different broken
behaviour; just after the end of first gc in cold-init, we take a path
through gencgc_handle_wp_violation(), whereupon I get a SIGSEGV in
vfprintf from the FSHOW statement at the head of that function.
I'm completely, utterly baffled.
> Did you notice any speed impacts? I would think make-sequence is
> pretty heavy-weight compared to make-sequence-of-type.
I don't think it's likely to be on the critical path of many things --
and I'm prepared to justify a small cost on the basis that MAKE-FOO is
going to be consing anyway, which speed-conscious inner-loops probably
shouldn't be doing.
But this talk of justification of small costs is a bit irrelevant if we
can't figure out what is going on on the x86...
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)