The problem is in the clean-up of OS-level locks. A lock is allocated using a combination of malloc() and pthread_mutex_init(), for example. The clean up was usually missing the free() to go along with pthread_mutex_destroy().
That's an especially basic mistake, and it slipped by because low-level locks are rarely allocated in the run-time system. Place channels are probably the simplest way to trigger new locks, but the test that checks for leaks with place channels uses the GC's count. I've pushed a repair as commit 641c56b6e9. I expect that patch would apply cleanly to v6.2.1. At Mon, 17 Aug 2015 15:02:35 +0100, Tim Brown wrote: > Folks, > > I am observing a memory leak with place-channels. I have long-lived (or > very busy server “places”) which I think are exhausting VM memory and > causing spectacular failures -- core dumps, spins and other fun I came > to Racket to avoid. Please could someone more familiar with the code > take a look at this? > > I would like to have absolute confidence in places and place channels > since they will be holding my application together. > > > --------------------------------------------------------- > #lang racket/base > (require racket/place) > (let mloop ((m 1000)) > (collect-garbage) > (displayln m) > (let kloop ((k 1000)) > ;(display #\tab) (displayln (current-memory-use)) > (let iloop ((i 1000)) > (place-channel) > (cond > [(> i 0) (iloop (sub1 i))] > [(> k 0) (kloop (sub1 k))] > [(> m 0) (mloop (sub1 m))])))) > --------------------------------------------------------- > > When I run the above program, using a stripped, non-debug version of > racket-6.2.1 (3m) it grows 0.5GB in 5 (998-993) “m” loops. (i.e. > 5,000,000 calls to place-channel). > > When I run it in a debug version, it doesn’t survive 140 “k” loops > (i.e. 140,000 calls to place channel). > > No matter where I explicitly call (collect-garbage). I do believe that > the places are being GCed, just they’re leaving something of themselves > behind. > > The documentation states: > > Place channels are subject to garbage collection, like other Racket > > values, and a thread that is blocked reading from a place channel can > > be garbage collected if place channel’s writing end becomes > > unreachable. However, unlike normal channel blocking, if otherwise > > unreachable threads are mutually blocked on place channels that are > > reachable only from the same threads, the threads and place channels > > are all considered reachable, instead of unreachable. > > And I don’t see how a call to (place-channel) can put it in a state as > described above. > > Verision info: > racket-6.2.1 (3m) > $ uname -a > Linux tim-8 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux > (debug version built with) > $ ../src/configure --prefix=/usr/local/racket/6.2.1-d --enable-backtrace > --disable-strip --enable-noopt > > Tim > > -- > Tim Brown CEng MBCS <tim.br...@cityc.co.uk> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > City Computing Limited · www.cityc.co.uk > City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB > T:+44 20 8770 2110 · F:+44 20 8770 2130 > ──────────────────────────────────────────────────────────────────────── > City Computing Limited registered in London No:1767817. > Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE > VAT No: GB 918 4680 96 > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
