From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 16 Sep 2005 10:16:50 -0400 From: Russ Cox To: Axel Belinfante Subject: Re: [9fans] leak In-Reply-To: <200509161129.j8GBTC302928@zamenhof.cs.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200509151601.j8FG12K29865@zamenhof.cs.utwente.nl> <200509161129.j8GBTC302928@zamenhof.cs.utwente.nl> Cc: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 8b4bb982-ead0-11e9-9d60-3106f5b1d025 > I submitted a patch to plug the leaks I encountered -- > should I also submit a patch for the setmalloctag's > I added to analyse what goes on? Please do. > > Or just think really hard. >=20 > even with leak(1) and additional setmalloctag calls > I already had to think hard enough to make sure > I did (free) the right thing (at the right place). For interactive programs, it's a bit easier. You do something 100 times and then run leak and look for blocks that have leaked 100, 200, etc. times. > Something else about leak: > when I run it in textual mode (no option or -s) > it doesn't report leaks. > when I run it in graphical mode (-b) I do get > red pieces in the picture. > This surprises (confuses) me a bit. I this this is a bug in aux/acidleak. I just fixed it. > > there was an older acid leak detection library that > > took a snapshot of the call stack on each allocation. > > that was useful, as you say. >=20 > (just curious) > any particular reason this was deprecated (assuming it is)? It had fallen into disrepair by the time I wanted to use it. The reason I wrote leak instead of fixing the old acid library is that the acid library doesn't help much with threaded programs. It ran the program with breakpoints at malloc and free, doing processing as the program ran. You can't do this once there are multiple procs running around. Also I wanted something that worked even if the program had already started. Russ