Custom Query (1030 matches)

On Win32 (Windows XP SP3), it seems CCL r14647 and later cause exceptions at the time of a disconnection.

This is the quote from *inferior-lisp* buffer:

%eax = 0x00000001
%ecx = 0x77bdc2e3
%edx = 0x00570608
%ebx = 0x012bb2b8
%esp = 0x015af510
%ebp = 0x015af528
%esi = 0x7ffaee88
%edi = 0x012bd320
%eip = 0x00026612
%eflags = 0x00010246

%cs = 0x001b
%ds = 0x0023
%ss = 0x0023
%es = 0x0023
%fs = 0x003b
%gs = 0x0000
Exception on foreign stack

%eax = 0x012b8998
%ecx = 0x015aee98
%edx = 0x00000001
%ebx = 0x7ffaee88
%esp = 0x015aeed0
%ebp = 0x015aeee8
%esi = 0x7ffdce88
%edi = 0x00000000
%eip = 0x00027255
%eflags = 0x00010287

%cs = 0x001b
%ds = 0x0023
%ss = 0x0023
%es = 0x0023
%fs = 0x003b
%gs = 0x0000
Exception on foreign stack

...

Can I ignore it?

ccl:temp-pathname on Android returns things like #P"/tmp/tmp\\.4.JYCET1462". That's not terribly useful as /tmp does usually not exist or is not accessible from non-root applications.

As per discussion on #ccl:

Finalizer ordering is currently arbitrary or backwards where it seems it should not be. (Note the definition of FINALIZE is essentially lifted from TRIVIAL-GARBAGE.)

;; This is a demonstration of finalization order in CCL.  When I run this,
;; I get the following output:
;;
;;     Finalize FOO 1
;;     Finalize FOO 2
;;     I would like #S(FOO) 2
;;     Finalize BAR 2
;;
;; This unfortunately means that if the FOO finalizer does something destructive
;; and permanent (like freeing a foreign value), BAR's finalizer can cause a
;; crash.

(defstruct (foo (:constructor %make-foo)))
(defstruct (bar (:constructor %make-bar)))

(defun finalize (object function)
  (ccl:terminate-when-unreachable object
                                  (lambda (obj)
                                    (declare (ignore obj))
                                    (funcall function)))
  object)

(defun make-foo (id)
  (let* ((foo (%make-foo)))
    (finalize foo (lambda () (format t "~&Finalize FOO ~A~%" id)))))

(defun make-bar (id)
  (let* ((foo (make-foo id))
         (bar (%make-bar)))
    (finalize bar
              (lambda ()
                (format t "~&I would like ~A ~A~%" foo id)
                (format t "~&Finalize BAR ~A~%" id)))))

(make-foo 1)
(make-bar 2)
(gc)

One would expect that FOO 2 would not be finalized until after BAR 2, because FOO 2 is referenced by BAR 2's finalizer lambda. I surmise that this is because the only reference to a finalizer is via its object, and therefore, anything the finalizer references becomes eligible for collection as soon as the object itself does.

A simple workaround is to simply strongly reference the lambda, and then make it dereference itself:

(defvar *strong-finalizers* (make-hash-table))

(defstruct (foo (:constructor %make-foo)))
(defstruct (bar (:constructor %make-bar)))

(defun finalize (object function)
  (setf (gethash function *strong-finalizers*) t)
  (ccl:terminate-when-unreachable object
                                  (lambda (obj)
                                    (declare (ignore obj))
                                    (funcall function)
                                    (remhash function *strong-finalizers*)))
  object)

(defun make-foo (id)
  (let* ((foo (%make-foo)))
    (finalize foo (lambda () (format t "~&Finalize FOO ~A~%" id)))))

(defun make-bar (id)
  (let* ((foo (make-foo id))
         (bar (%make-bar)))
    (finalize bar
              (lambda ()
                (format t "~&I would like ~A ~A~%" foo id)
                (format t "~&Finalize BAR ~A~%" id)))))

(make-bar 2)
(gc)

(make-foo 1)
(gc)
(gc)
(gc)

In this case, the finalizer for FOO 2 is not called until the next cycle (though it appears to take some allocation and a cycle or two to make it notice).