At Tue, 18 Aug 2015 10:40:14 -0400, George Neuner wrote: > On Mon, 17 Aug 2015 10:07:11 -0600, Matthew Flatt > <mfl...@cs.utah.edu> wrote: > > >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. > > Is it safe to assume this problem also is in 6.1.1?
Yes. > I'm currently > investigating adding places into an existing webserver based > application, but I haven't gotten far enough along to notice any > leaking. Just to be clear, your application would have to allocate thousands of place channels before the leak becomes measurable. Allocating places would also leak, since they create place channels, but a place is heavyweight enough that I don't think you can create places fast enough to measure the small leak. (Allocating thousands of place channels is a perfectly reasonable thing to do, but most uses of places don't do that.) -- 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.
