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.
