Summary

Possible memory leak related to mutexes

Metadata

Description

The following program eats up all the memory fairly quickly.

Two methods to make it not do that: 1. Comment out the `mutex-lock!` and `mutex-unlock!` calls, or 2. uncomment the `(gc)` call.

Tested with 4.12.

 (use (only srfi-18 mutex-lock! mutex-unlock! thread-yield! make-thread thread-start!))
 (use (only extras format))
 
 (define (make-philosopher name mtx)
   (thread-start!
    (make-thread
     (lambda ()
       (mutex-lock! mtx)
       ;; (print name " eating" mtx)
       (mutex-unlock! mtx)
       ;(gc) ; <- Uncommenting this seems to stop unbounded growth
       (make-philosopher name mtx)))))
 
 (let ((mtx-food (make-mutex 'food)))
   (let lp ((i 0))
     (when (< i 5)
       (print "start philosopher-" i)
       (make-philosopher (string->symbol (format "philosopher-~a" i)) mtx-food)
       (lp (add1 i))))
   (let lp ()
     (thread-sleep! 100)
     (lp)))

Changes and comments

[2017-05-05 19:20:45 UTC] sjamaan changed milestone from someday to 4.13.0

[2017-08-25 15:36:15 UTC] sjamaan set difficulty to insane

[2017-10-10 17:59:10 UTC] sjamaan wrote:

This looks like a small bug in the scheduler: ##sys#schedule "pollutes" the thread thunk with its own continuation, which holds a reference to the old thread. With the test program here this results in a pathological cascade of references all the way back to the primordial thread, with each new philosopher thread adding onto that chain. Patch sent to chicken-hackers.

[2017-10-22 14:00:33 UTC] kooda changed status from new to closed

[2017-10-22 14:00:33 UTC] kooda set resolution to fixed

[2017-10-22 14:00:33 UTC] kooda wrote:

Fix pushed on 118fcebbb7fcaf85aa2842806d3f5ee8fb2d14b6 and 596332d69e47a5d04fe5e4f5f609c3e4ab8fcdba