[Top][All Lists]

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

[MIT-Scheme-devel] verify_heap

From: Matt Birkholz
Subject: [MIT-Scheme-devel] verify_heap
Date: Sat, 26 Apr 2014 13:59:56 -0700

The tests now generate far fewer SIGFPEs, so trap recovery has not
been tripping the assert in linkage_section_type[cmpint.c:1740]
during `make check', BUT the problem is still there.

I wrote a debugging function, verify_heap, that scans the heap much
like find_block_address.  It complains on stderr instead of aborting.
>From the commit 6b40ed6 message:

    The new verify_heap function scans the heap in the same way, and
    complains on stderr about any invalid linkage section types, object
    types, etc.  If the GC_Debug flag is set, verify_heap is called by the
    garbage-collect primitive to scan maximal heap.

I used the GC_Debug flag because it did not seem to be in use.  (Did I
missing something?)  I turn on verify_heap's scans during `make check'
by adding the following line at the top of tests/check.scm.

    ((make-primitive-procedure 'SET-DEBUG-FLAGS! 2) 9 #t)

I got 7110 complaints the first time.  The dump_heap_at function
revealed that the bogosities often start at the end of a bignum or
string.  Looking for code adjusting bignum and string lengths revealed
culprits BIGNUM_REDUCE_LENGTH and %string-head!.  Fixing the first one
alone eliminated 7093 complaints.

The remaining complaints happen only after SIGFPE trap recovery.
Looking for trap recovery code that frobs Free reveals

uxtrap.c:414:     Free += FREE_PARANOIA_MARGIN;

in continue_from_trap, which explains why dump_heap_at was dumping
broken-hearts (typical of from space) before the obvious bogosities.

I deleted the whole /* Sanity-check Free.  */ section from continue_
from_trap and now `make check' completes clean -- nary a complaint
from verify_heap.



  * Even when !ENABLE_TRAP_RECOVERY, Free is set to heap_alloc_limit.
    Why force a GC before the trap handler runs?

  * Is all this paranoia necessary today?  On Unix with HAVE_

  * Is there more code that leaves "holes" in the heap?

I pushed all but the last "fix" to Savannah before I looked for good
builds on all my architectures.  Mea culpa in advance...

reply via email to

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