[Openmcl-devel] CCL crash in GSLL

[Liam Healy]

On Thu, Jul 8, 2010 at 9:59 PM, Daniel Herring <dherring at tentpost.com> wrote:
>
> Valgrind may be another tool worth using.

Interesting suggestion.  I have no experience with valgrind and just
took a quick look at the "quick start" guide.  Do you have experience
using valgrind with CCL?  It's not clear to me how they would be
combined, and how to trace problems back into lisp.

>
> - Daniel
>
> P.S.  There don't appear to be many places in gsll that free memory; it may
> be possible to trace all of them.  Or put a trace on every function in the
> package and see which one is called last.
>

That is true, there aren't many places.  The problem with putting traces on
or anything similar is there is a delayed error here.  That is, I can run
(lisp-unit:run-tests matheiu) once just fine, and only on the second successive
run does it crash.  So the triggering form is not the at-fault form.

On the bright (?) side, SBCL is now showing an identical error on a different
branch of GSLL.  I had hoped the rewriting of GSLL and components would
eliminate the problem in CCL, but that's not the case.

CORRUPTION WARNING in SBCL pid 12603(tid 140737354000128):
Memory fault at 0 (pc=0x7ffff744f2e8, sp=0x7ffff5190040)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
; in: LAMBDA NIL
;     (LISP-UNIT:ASSERT-NUMERICAL-EQUAL
;      (LIST -0.9285480638845388d0 4.440892098500626d-16)
;      (MULTIPLE-VALUE-LIST (GSLL:MATHIEU-CE 10 15.0d0 (/ PI 2))))
; --> LISP-UNIT::INTERNAL-ASSERT
; ==>
;   #'(LAMBDA () (LIST))
;
; caught WARNING:
;   Error calling finalizer #<CLOSURE (LAMBDA ()) {1007301979}>:
;     #<SB-SYS:MEMORY-FAULT-ERROR {10048FD0F1}>

The additional information here is that it's coming from a finalizer.
However, I've failed at my attempts to find which finalizer.
The other useful fact is that SBCL doesn't hard-crash;
I can get back to a lisp prompt if I'm careful, though
sometimes I end up in ldb.  I haven't been able to figure out
how to exploit that yet, however.

Liam