chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] [PATCH] Small fix to stabilize behavior [Was: Re: [PAT


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Small fix to stabilize behavior [Was: Re: [PATCH] limit number of live finalizers]
Date: Sat, 23 Jun 2012 19:51:08 +0200
User-agent: Mutt/1.4.2.3i

On Sat, Jun 23, 2012 at 02:53:21PM +0200, Peter Bex wrote:
> > User programs can override the finalizer limit using the "-:f" runtime
> > option if a large number of finalizations are expected or required in 
> > specific applications.
> 
> I'd like a little more time to investigate the bug.  This patch can
> always be applied.  It would be a shame if we can come up with a better
> fix after this makes it into the release.

Here's a patch that made one test function correctly.  The test is my
own simplified version of Megane's test:

(let lp ((x (list 1 2 3)))
  (set-finalizer! x (lambda _ #f))
    (lp (list 1 2 3)))

This test used to fail with something like this:

Warning: in finalizer: call of non-procedure: #<unspecified>

        Call history:

        /tmp/test.scm:3: lp       
        /tmp/test.scm:2: set-finalizer!   
        [...]
[panic] out of memory - heap full while resizing - execution terminated

After applying the patch, it just loops endlessly (which is the correct,
expected behavior) without any errors.

About the patch:

##sys#fudge 26 returns the number of live finalizers, which (I think)
should be identical to the value of the first slot in the
##sys#pending-finalizers.  In any case, the check in set-finalizer!
compares if fudge 26 is LARGER than the maximum number of pending
finalizers.  If that's the case, we're actually already storing one
finalizer more than the vector can take.

Originally I overlooked it because (fx+ (fx* 2 _max_pending_finalizers) 1)
looks like it can hold one more finalizer than _max_pending_finalizers,
but then I figured that the vector is twice the size of
_max_pending_finalizers because it holds pairs of values and their
associated finalizer procedure.  The +1 is for the extra slot that keeps
track of the number of finalizers.
Question: Why the duplication with live_finalizer_count?  Are these
two values subtly different somehow?

Anyway, the attached patch changes fx> to fx>= which makes the error go
away with my test case.  Unfortunately, the tests/finalizer-error-test
still fails.  I have some hopes to get that fixed too.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: 0001-Fix-finalizer-size-check-if-it-s-bigger-we-re-alread.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]