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.
Questions:
* Why FREE_PARANOIA_MARGIN?
* 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_
SIGCONTEXT?
* 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...
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
