At Mon, 17 Aug 2015 12:21:41 -0700 (PDT), Jack Firth wrote: > On Monday, August 17, 2015 at 9:07:15 AM UTC-7, Matthew Flatt wrote: > > 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. > > Would it be worthwhile to hook up a tool like Valgrind for catching these > sorts of VM memory bugs to the Travis CI builds and tests of Racket? (Or is > there already some such process in the builds, in which case why didn't it > catch this?) From my limited experience with C, I've learned it's pretty much > impossible to expect any sane human to keep track of memory perfectly.
The last time I tried Valgrind was in March. I got it to work with some small adjustments to Racket: http://lists.racket-lang.org/users/archive/2015-March/066287.html I'm sure more could be done with Valgrind. Catching a bug like the one with place channels in an automated way would be difficult; it would be a matter of calling the right function enough to distinguish it from once-per-process allocations that are intended to be cleaned up implicitly by the process exiting. Although the runtime system has a lot of C code, memory leaks are relatively rare because most allocation is through the GC --- even for internal data structures. In other words, I mostly work in garbage-collected dialect of C. -- 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.
