[Openmcl-devel] CCL crash in GSLL

[Liam Healy]

Just to close the issue, I found the error, but not with any
of the mentioned tools.  SBCL was giving me slightly
better diagnostic messages and I was able to figure out
what test form was causing the failure.  I took a closer look at the
source code and found a fencepost problem in the Mathieu
functions (minimum order to maximum order are put
in the array, which means array length must be
max - min + 1, and I was missing the +1).  I've committed
the fix in the "convert" branch which will be merged
to master soon.

Thanks for the ideas anyway, it's good to know what
tools are useful for this kind of problem.

Liam

On Sat, Jul 10, 2010 at 2:20 PM, Liam Healy <lnp at healy.washington.dc.us> wrote:
> 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
>