[Cc to mailing list.]

Hi Michael!

On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" goffioul@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.