From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA09010; Thu, 24 Apr 2003 15:09:59 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA09064 for ; Thu, 24 Apr 2003 15:09:58 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h3OD9uH24372; Thu, 24 Apr 2003 15:09:56 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA09156; Thu, 24 Apr 2003 15:09:55 +0200 (MET DST) Date: Thu, 24 Apr 2003 15:09:55 +0200 From: Xavier Leroy To: Chris Hecker Cc: caml-list@inria.fr Subject: Re: [Caml-list] Str memory leak in 3.06? Message-ID: <20030424150955.C5587@pauillac.inria.fr> References: <4.3.2.7.2.20030424001900.037a2958@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.3.2.7.2.20030424001900.037a2958@localhost>; from checker@d6.com on Thu, Apr 24, 2003 at 12:41:14AM -0700 X-Spam: no; 0.00; caml-list:01 3.06:01 ocamlopt:01 foo:01 inserting:01 slows:01 debugger:01 glance:01 finalizer:01 grovel:01 regex:01 bug:01 regexps:01 601:99 alloc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > This program leaks 10mb/sec on my machine with ocamlopt 3.06 (msvc, xp). > > let _ = > while true do > let re = Str.regexp "foo" in () > done; > () > > Inserting a call to Gc.compact in the loop doesn't affect it (well, it > slows the loop down a bit so the leak rate drops :). > > From a brief trip in the debugger and a glance at strstubs.cpp it appears > the custom finalizer is being called. I didn't grovel in the actual regex > code to see where the leak was (assuming it's not my bug and I'm supposed > to free the regex somehow in caml code). No, there is no need for explicit deallocation of regexps. Actually, there is no leak either: if you put a call to Gc.major() in the loop, memory usage remains constant. What happens is that the speed of the (incremental) major collector isn't appropriately adjusted, so it runs too slowly and lets "floating garbage" accumulate. This is a common problem with Caml objects that are just handle on resources allocated outside the Caml heap: precise determination of the space consumption of the latter is generally impossible, causing the incremental major GC to run often too slowly, sometimes too fast... > I also notice that the strstubs.c has the same problem I reported in > bigarray (and that was fixed, bug #601) about using stat_alloc() to > allocate but free() to deallocate, so it should probably be fixed here as > well, assuming Str is going to live much longer. The new implementation of Str that will go in release 3.07 allocates all its data in the Caml heap, so this fixes both the issue you mention and the "floating garbage" problem described above. Best wishes, - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners