port-for-each vs lazy sweep

[Kevin Ryde]

I've struck, in 1.8, port-for-each passing a freed cell to its iterator
func.  Eg. "guile -s foo.scm" on

    (define lst '())
    (gc) (gc) (gc)
    (make-list 1000)
    (open-input-file "/etc/passwd")
    (make-list 1000)
    (open-input-file "/etc/passwd")
    (make-list 1000)
    (open-input-file "/etc/passwd")
    (make-list 1000)
    (open-input-file "/etc/passwd")

    (gc)

    (port-for-each (lambda (port)
                     (set! lst (cons port lst))))
    (gc) (gc) (gc)

    (display lst) (newline)

gives

    (#<freed cell 0xb7c3bd20; GC missed a reference> #<freed cell 0xb7c3ed78; 
GC missed a reference> #<freed cell 0xb7c41558; GC missed a reference> #<input: 
port-weak.scm 5> #<output: standard error /dev/pts/2> #<output: standard output 
/dev/pts/2> #<input: standard input /dev/pts/2> #<input-output: string 805d030> 
#<output: string 805cf70>)


I suspect the opened ports are correctly found to be unused and left
unmarked by the gc, but they remain in the port table.  port-for-each
then passes them to its func and a little later the sweep gets to them
and they turn into freed cells.  (I noticed this when printing ports
from within port-for-each as a diagnostic.)

I suppose either port-for-each should ignore ports which are unmarked
and unswept; or the gc should sweep the port table entries immediately
instead of lazily.  Neither sounds pretty, but the latter might be safer
than letting zombies remain in the port table.  I suspect for instance
`flush-all' could suffer the same problem if it does a callback to a
soft port flush function (or a C code ptob flush func if that somehow
provoked some sweeping).

(This got me wondering why there's a port table anyway, instead of
independent objects with say a weak hash table for the "list of all
ports" needed by port-for-each and flush-all.  Historical reasons I
suppose.)