[rdnzl-devel] Re: Problem/crash with RDNZL under ECL

[Edi Weitz]

[Cc to mailing list.]

Hi Michael!

On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> I discovered a crash problem at exit-time due to RDNZL under ECL.  I
> didn't notice it until recently because the application exited
> without notice about the crash. The problem is related to
> DelegateAdapter class and the release callback. It seems that the
> CLR registers an exit-hook function, I guess to run one last time
> the GC to release any allocated resources. DelegateAdapter objects
> are only released during that phase: I tried various combination of
> GC forcing in LISP and CLR, but those objects got never collected,
> except during the exit-hook. The problem is that this exit-hook is
> run after the LISP engine unloading, such that the release callback
> registered in the DelegateAdapter class just points to garbage
> memory.

Ouch...

> I don't know what's going on. I tried various workaround, without
> touching RDNZL code, but couldn't avoid the crash. Currently, the
> only solution I'm left with is to set the invoke and release
> callbacks of DelegateAdapter class to null before exiting and add
> nullity-check code to DelegateAdapter class before calling those
> callbacks.

Seems like a reasonable solution.

> Did you ever have that problem?

No, but I never ran anything under the VS debugger.

> In my case, I can easily reproduce it by running my LISP into the
> Visual Studio debugger and run the apropos example.  On exit, I'm
> warned by the debugger about the access violation. Note that if I
> run the LISP outside the debugger, I'm not notified at all.

I just tried with VS 2003.  I started LispWorks 5.0, then attached the
VS debugger to LW, then loaded RDNZL, then loaded and ran the apropos
example.  Finally, I quit LispWorks.  I didn't get any messages,
though.  Maybe this only happens with .NET 2.0?  Or is it specific to
ECL?  Or do I have to do something else?  I'm not familiar with the VS
debugger.

Nevertheless, it's pretty disturbing that DelegateAdapter objects are
/never/ released... :(

Cheers,
Edi.