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.)
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
