Opened 7 years ago

Closed 6 years ago

#1367 closed defect (fixed)

Possible memory leak related to mutexes

Reported by: megane Owned by:
Priority: not urgent at all Milestone: 4.13.0
Component: core libraries Version: 4.12.0
Keywords: srfi-18 Cc:
Estimated difficulty: insane

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)))

Change History (4)

comment:1 Changed 7 years ago by sjamaan

Milestone: someday4.13.0

comment:2 Changed 7 years ago by sjamaan

Estimated difficulty: insane

comment:3 Changed 6 years ago by sjamaan

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.

comment:4 Changed 6 years ago by Kooda

Resolution: fixed
Status: newclosed

Fix pushed on 118fcebbb7fcaf85aa2842806d3f5ee8fb2d14b6 and 596332d69e47a5d04fe5e4f5f609c3e4ab8fcdba

Note: See TracTickets for help on using tickets.