Copyright 1998 Lars T Hansen.                -*- text -*-

$Id$


			  List of bugs retired
		 (not fixed but no longer reproducible)
		     ------------------------------


027  (v0.28c(?)) 970609

     Message-ID: <3399DA5B.CEE@ccs.neu.edu>
     Date: Sat, 07 Jun 1997 17:02:22 -0500
     From: William D Clinger <will@ccs.neu.edu>
     To: lth@ccs.neu.edu
     Subject: FYI: progress on the non-predictive collector
     
     [...]

     While tracking this down I encountered a repeatable segmentation
     fault, which occurs with the old version of cheney.c as well as
     the new version.  It can be replicated with:
     
     % cd /proj/will/Benchmarks
     % larc0 -np -steps 100
     > (load "temp.sch")
     > (foo 0)
     > (foo 0)
     > (foo 4)
     > (foo 4)
     > (display-memstats (memstats))
     > (define (gc)
         (collect 1 'collect)
         (collect 2 'collect)
         (collect 3 'collect)
         (display-memstats (memstats)))
     > (gc)
     > (foo 4)
     
     I will leave "larc0" and "temp.sch" alone until this bug is
     fixed.
     
     Will

     COMMENTS:

     That command line expands to 
        larceny -heaps 2 -size1 1024K -steps 100 -stepsize 256K -lomark2 1 \
		-himark2 100 -lomark3 1 -himark3 100 larceny.heap
     where larceny.heap is really /proj/will/Larceny0.28b/larceny.heap.

     This crash is not repeatable in 0.28d with the 0.28d heap image and 
     my own set of {dynamic.sch, dynamic.fasl} files.  Will has since
     recompiled dynamic.sch, so my files (April 30) are probably closer to
     the originals.

     It is also not repeatable in 0.28d with the 0.28b heap image and my
     own set of {dynamic.sch, dynamic.fasl} files.

     It is also not repeatable in 0.28c as built by Will on 6/11, with the
     0.28c heap image.

     TO DO:

     Need to check how this works in v0.28b (last full distribution).

029  (v0.28c) 970612

     Message-ID: <339EFE09.176@ccs.neu.edu>
     Date: Wed, 11 Jun 1997 14:36:11 -0500
     From: William D Clinger <will@ccs.neu.edu>
     To: lth@ccs.neu.edu
     Subject: a more significant segmentation fault
     
     Here's a more bothersome segmentation fault, which occurs following
     a non-predictive gc.  I've copied all of the files to *.bug.
     
     Will
     
     ----
     
     [Benchmarks]% !!
     larc2 -calibrate -steps 62 -himark3 100
     Calibration run using non-predictive collector
     Larceny v0.28c/precise (SunOS;split) (will/Wed Jun 11 13:36:01 EDT 1997)
     Non-predictive hi_mark=100, lo_mark=0, oflo_mark=80.
     GC type: sc/fixed+2*sc/variable+static
     
     Heap statistics:
     Generation 0
       Size of semispace 1: 262144 bytes
       Size of semispace 2: 262144 bytes
       Live data: 0 bytes
       Live stack: 0 bytes
     Generation 1
       Size of semispace 1: 524288 bytes
       Size of semispace 2: 0 bytes
       Live data: 0 bytes
     Generation 2
       Size of semispace 1: 16252928 bytes
       Size of semispace 2: 0 bytes
       Live data: 0 bytes
     Generation 3
       Size of semispace 1: 0 bytes
       Size of semispace 2: 0 bytes
       Live data: 0 bytes
     Generation 4
       Size of semispace 1: 825344 bytes
       Size of semispace 2: 0 bytes
       Live data: 825344 bytes
     
     > (load "temp.m.sch")
     > (promote-always)
     > (load "gcbench1.fasl")
     > (define vecs
         (measurements (lambda () #t) gc-benchmark 0))
     
     j=0
     GC in the non-predictive heap: k=62, j=0.
     Finished non-predictive GC; k=62, j=0.
     GC in the non-predictive heap: k=62, j=0.
     Finished non-predictive GC; k=62, j=0.
     The garbage collector should touch about 32 megabytes of heap storage.
     The use of more or less memory will skew the results.
     
     --------------------------------------------------------
     GCBench18
     Garbage Collector Test
      Stretching memory with a binary tree of depth 18
      Total memory available= ???????? bytes  Free memory= ???????? bytes
     
     --------------------------------------------------------
     GCBench: Main
      Creating a long-lived binary tree of depth 16
      Creating a long-lived array of 524284 inexact reals
     Non-predictive 'old' area overflowed by 494528 bytes.
     GC in the non-predictive heap: k=62, j=0.
     Finished non-predictive GC; k=62, j=0.
      Total memory available= ???????? bytes  Free memory= ???????? bytes
     Creating 33824 trees of depth 4
     
     --------------------------------------------------------
     GCBench: Top down construction
     Words allocated: 6291936
     Words reclaimed: 6255936
     Elapsed time...: 3094 ms (User: 3080 ms; System: 10 ms)
     Elapsed GC time: 700 ms (in 96 collections.)
     
     --------------------------------------------------------
     GCBench: Bottom up construction
     Words allocated: 6291936
     Words reclaimed: 6266580
     Elapsed time...: 2884 ms (User: 2530 ms; System: 30 ms)
     Elapsed GC time: 343 ms (in 96 collections.)
     Creating 8256 trees of depth 6
     
     --------------------------------------------------------
     GCBench: Top down construction
     Words allocated: 6291744
     Words reclaimed: 6239014
     Elapsed time...: 2754 ms (User: 2740 ms; System: 10 ms)
     Elapsed GC time: 331 ms (in 96 collections.)
     
     --------------------------------------------------------
     GCBench: Bottom up construction
     Words allocated: 6291744
     Words reclaimed: 6340534
     Elapsed time...: 2707 ms (User: 2600 ms; System: 10 ms)
     Elapsed GC time: 389 ms (in 96 collections.)
     Creating 2052 trees of depth 8
     
     --------------------------------------------------------
     GCBench: Top down construction
     Words allocated: 6292104
     Words reclaimed: 6213388
     Elapsed time...: 2828 ms (User: 2830 ms; System: 0 ms)
     Elapsed GC time: 398 ms (in 96 collections.)
     
     --------------------------------------------------------
     GCBench: Bottom up construction
     Words allocated: 6292104
     Words reclaimed: 6445302
     Elapsed time...: 2698 ms (User: 2690 ms; System: 10 ms)
     Elapsed GC time: 446 ms (in 97 collections.)
     Creating 512 trees of depth 10
     
     --------------------------------------------------------
     GCBench: Top down construction
     Words allocated: 6289056
     Words reclaimed: 6157312
     Elapsed time...: 3352 ms (User: 3090 ms; System: 0 ms)
     Elapsed GC time: 685 ms (in 96 collections.)
     
     --------------------------------------------------------
     GCBench: Bottom up construction
     Words allocated: 6289056
     Words reclaimed: 6410754
     Elapsed time...: 3062 ms (User: 3040 ms; System: 20 ms)
     Elapsed GC time: 799 ms (in 96 collections.)
     Creating 128 trees of depth 12
     
     --------------------------------------------------------
     GCBench: Top down construction
     Words allocated: 6291360
     Words reclaimed: 6163250
     Elapsed time...: 3939 ms (User: 3920 ms; System: 20 ms)
     Elapsed GC time: 1504 ms (in 96 collections.)
     
     --------------------------------------------------------
     GCBench: Bottom up construction
     Words allocated: 6291360
     Words reclaimed: 6347916
     Elapsed time...: 4533 ms (User: 4530 ms; System: 10 ms)
     Elapsed GC time: 2266 ms (in 96 collections.)
     Creating 32 trees of depth 14
     
     --------------------------------------------------------
     GCBench: Top down construction
     Words allocated: 6291936
     Words reclaimed: 4621340
     Elapsed time...: 6811 ms (User: 6450 ms; System: 10 ms)
     Elapsed GC time: 4284 ms (in 96 collections.)
     
     --------------------------------------------------------
     GCBench: Bottom up construction
     Non-predictive 'old' area overflowed by 476344 bytes.
     GC in the non-predictive heap: k=62, j=0.
     Finished non-predictive GC; k=62, j=0.
     Non-predictive 'old' area overflowed by 453784 bytes.
     GC in the non-predictive heap: k=62, j=0.
     Segmentation fault
     

     COMMENTS:
     The command line expands as
       larceny -heaps 3 -stats -annoy-user \
        -size1 256K -lomark1 0 -himark1 100 -oflomark1 25 \
        -size2 512K -lomark2 0 -himark1 100 -oflomark2 48 \
        -steps 62 -stepsize 256K -himark3 100 larceny.heap
     where all the files are in Bugs/029.
     [The third line has a bug -- should be himark2.]

     The segmentation fault happens in realloc(); here's the traceback:

Program received signal SIGSEGV, Segmentation fault.
0xef77dbbc in realloc ()
(gdb) where
#0  0xef77dbbc in realloc ()
#1  0x4f88 in must_realloc (ptr=0x252b8, bytes=320) at Sys/malloc.c:42
#2  0xd6f4 in extend_chunk_array (s=0x23880) at Sys/semispace.c:124
#3  0xd56c in ss_expand (s=0x23880, bytes_request=262144) at Sys/semispace.c:90
#4  0xf9c4 in expand_semispace (ss=0x23880, lim=0xefffed94, dest=0xefffed90, 
    bytes=262144) at Sys/cheney.c:878
#5  0xea00 in scan_oflo_normal (scanptr=0x52b0ac, scanlim=0x538000, 
    scan_chunk_idx=0, e=0x1e7d8, iflush=1) at Sys/cheney.c:707
#6  0xe86c in scan_oflo (scanptr=0x4f8000, scanlim=0x538000, scan_chunk_idx=0, 
    e=0x1e7d8, iflush=1, may_be_partial=0) at Sys/cheney.c:688
#7  0xdcb8 in oldspace_copy (gc=0x234a0, tospace=0x23880, tospace2=0x0, 
    effective_generation=0, may_be_partial=0, op=5472256) at Sys/cheney.c:585
#8  0xda6c in gclib_copy_younger_into (gc=0x234a0, tospace=0x23880)
    at Sys/cheney.c:471
#9  0x10228 in internal_collect (heap=0x238a8) at Sys/np-sc-heap.c:410
#10 0x1011c in internal_promote (heap=0x238a8, force_collection=0)
    at Sys/np-sc-heap.c:377
#11 0xfed4 in promote (heap=0x238a8) at Sys/np-sc-heap.c:272
#12 0x9b44 in promote_out_of (gc=0x234a0, generation=1) at Sys/memmgr.c:597
#13 0xbb0c in collect (heap=0x237b0) at Sys/old-heap.c:250
#14 0xba1c in promote (heap=0x237b0) at Sys/old-heap.c:202
#15 0x9b44 in promote_out_of (gc=0x234a0, generation=0) at Sys/memmgr.c:597
#16 0xb364 in collect (heap=0x23710, request_bytes=20) at Sys/young-heap.c:281
#17 0x9a7c in collect (gc=0x234a0, generation=0, type=GC_COLLECT, 
    request_bytes=20) at Sys/memmgr.c:535
#18 0x12ac8 in garbage_collect3 (gen=0, type=0, request_bytes=20)
    at Sys/gc.c:78
#19 0x2498 in C_garbage_collect (type=0, request_words=20) at Sys/cglue.c:22
#20 0x5704 in internal_callout_to_C ()
#21 0x1c4c4 in globals ()

     Error is not repeatable in working version of 0.28d. (Sigh.)

     Error is also not repeatable in v0.28b (as distributed).  Notably,
     promote-always was not supported in 0.28b, and heap contraction was
     still in place, so the memory behavior should be pretty different in
     0.28b vs. later versions.


044  v0.31 (971024 / lth)  Retired 971030

     In Rts/Makefile, 'as' should probably be '/bin/as' always, because
     at CCS, some people's path points to the GNU directories, and gas
     does not accept the -P (preprocess) command-line switch.

     Reason for retiring: /bin/as isn't right on SunOS 5.


068 v0.34 (ancient bug, maybe as old as v0.20)  Retired 981203 by lth
    Priority: low

    Float-significand and float-exponent, as visible in the interaction
    environment, should be more discriminating about the types of their
    arguments:

	> (float-significand "123456789abc")
	6253164108014179
	> (float-exponent "123456789abc")
	-224

    Reason for retiring: removed float-significand and float-exponent
    from the interaction environment.

094 v0.41 (981221 / lth)  Retired 991117 by lth
    Priority: medium.
    Category: TWOBIT / correctness

    Block compiler and primitive definitions interact poorly.  The following
    hangs:

       (define car (lambda (x) (car x)))

098 v1.0a1 (981221 / wdc)  Retired 2000-09-28 by lth
    Priority: medium.
    Category: INTERPRETER / correctness

    Define-inline works in larceny.heap but not in r5rs.heap.

    Retired because DEFINE-INLINE is no longer available.

099 v1.0a1 (990104 / lth)  Retired 2000-09-28 by lthy
    Priority: medium.
    Category: INTERPRETER / correctness
    See also: 084, 085, 153

    define-inline is available in scheme-report-environment and 
    null-environment but should not be:

	> (eval '(define-inline foo (syntax-rules () ((foo x) x))) 
                (scheme-report-environment 5))

    Retired because DEFINE-INLINE is no longer available.

123 v1.0a1 (990421 / lth)  Retired 990818 by lth
    Priority: low
    Category: TWOBIT / performance

    [May have been fixed since]

    The macro for DO produces worse code than it needs to: if there
    are no <expression>s following the <test> it returns the value
    of the <test>, which means that the compiler will generate 
    code to evaluate the boolean for its value, resulting in numerous
    needless operations.

    Reason for retiring: had been fixed by other compiler fixes, but
    unknown which.

153 v0.48 (2000-04-03 / dougo)  Retired 2000-09-28 by lth
    Priority: medium
    Category: TWOBIT / correctness
    See also: 084, 085, 099

    >What's up with this?
    >
    >> (eval 'car (null-environment 5))
    >Error: Undefined global variable "car".
    >Type (debug) to enter debugger.
    >> (eval '(car '(1 2)) (null-environment 5))
    >1
    >
    >What exactly is defined in the null environment?  I thought it was
    >only supposed to have syntactic keywords?
    
    Yes, but there are bugs... CAR is a primitive, but LIST-REF is not, so
    let's try LIST-REF:
    
      > (eval '(list-ref '(1 2) 0) (null-environment 5))
    
      Error: Undefined global variable "list-ref".
      Entering debugger; type "?" for help.
    
    The problem is that the compiler open-codes CAR so an environment
    reference is not made.  The bug is that the environment does not have a
    distinguished primitive table, in the same way that it does not have a
    distinguished macro environment (known bug).

    Comment 2000-09-21 / lth

    This is somewhat deep.  The "right way" here would might be
    to restrict the primitives for a compilation based on which top-level
    environment is in use.  Currently we don't do that, and it seems
    really complicated to do it, maybe even unnecessary.  The right
    way to do the above is

	(parameterize ((integrate-procedures 'none))
          (eval '(car '(1 2)) (null-environment 5)))

    which restricts both the top-level bindings available as well as
    the primitives available.  Crufty, sure, but would it really be
    better if this were an implicit fact of passing null-environment
    to EVAL?  Not sure...

    Retired because I decided that the above behavior is correct.

; eof
