I'm looking into this. I can confirm that the GC thinks there's no leak, but the OS thinks there is.
Thanks for the example and info! At Mon, 17 Aug 2015 16:09:00 +0100, Tim Brown wrote: > Sam, > > I don’t see the leak with (display (current-memory-use)) -- sorry for > leaving it in the example, it’s misleading since your numbers behave > like mine did when I used that function. > > I *do*, however, see the leak on my gnome-system-monitor; which looks > like something that’s invisible to the GC falling off its radar. > > Could you see if your favourite system memory monitor shows any growth? > > Thanks, > > Tim > > On 17/08/15 15:45, Sam Tobin-Hochstadt wrote: > > Hi Tim, > > > > I just tried this out on HEAD, and I don't see the leak you mention. > > Here's some representative output, with somewhat fewer printouts. > > > > 987 > > 19197408 > > 23120744 > > 22890272 > > 22708784 > > 22102128 > > 29001640 > > 27675528 > > 21492328 > > 22373784 > > 29436848 > > 28895592 > > > > I've never seen a number starting with 3 in running this program. I know > > Matthew has fixed some leaks recently, so maybe that's what's reduced this. > > > > Sam > > > > > > On Mon, Aug 17, 2015 at 10:03 AM Tim Brown <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> > > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > > City Computing Limited · www.cityc.co.uk > > <http://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 [email protected] > > <mailto:racket-users%[email protected]>. > > For more options, visit https://groups.google.com/d/optout. > > > > > -- > Tim Brown CEng MBCS <[email protected]> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
