Just for if it is of any value in understanding the problem, find below the variables bound to all of those stack frames and their liveness.

Will be very happy to understand the nature of this issue further. To start with, it is rare.


Dumping was done by

(define (frame-o frame)
  (map-interval (lambda (i) (list (##frame-ref frame i) (##frame-slot-live? frame i)))
                0 (- (##frame-fs frame) 1)))


For reference, I got that "*** FATAL ERROR -- GC inconsistency detected" error I mentioned in an earlier email, when I resolved the references to #<frame one deeper than f> below. Find console output for that attached here.


2013/6/20 Mikael <mikael.rcv@gmail.com>
 
A stack frame is referencing it, which is of a procedure that I provide, whose invocation ended long ago.

((5140 #f)
 (#<procedure #N> #t)
 (300 #t)
 (THE-IO-VECTOR #t)
 (#t #t)
 (1080 #t)
 (#<frame one deeper than f> #t)
 ("http" #t)
 (50 #t))

 
That stack frame in turn is referenced by the procedure that created the vector.
 
> (frame-o f2)
((3092 #f) (#<input-output-port #N (tcp-client)> #t) (#t #t) (#&#!eof #t) (#<mutex #N> #t) (#<frame f > #t) (#t #t) (() #t) (#<unknown> #f))

And that stack frame in turn is referenced by ##read-u8 (!)

> (frame-o f3)
((3092 #f) (#<frame f2? > #t) (#<input-output-port #N (tcp-client)> #t) (#\U32bfaeaf #f) (#\U32bfaeaf #f))

And that stack frame in turn is referenced by ##byte-rbuf-fill (!)
 
> (frame-o f4)
((1044 #f) (-515899357 #t) (#<frame f3? > #t) (#<input-output-port #N (tcp-client)> #t) (1 #t))

And that stack frame in turn is referenced by ##wait-for-io! (!)

> (frame-o f5)
((1044 #f))
 
And that stack frame in turn is referenced by ##thread-interrupt! (!)

> (frame-o f6)
((3092 #f))
 
And that stack frame in turn is referenced by ##thread-call (!)

> (frame-o f7)
((1026 #f) (#<frame  f6?? > #t) (#<procedure #N > #t) (-5 #f) (4 #f))