Subject: Re: Memory leaks
From: Paul Rohr (paul@abisource.com)
Date: Tue Jun 19 2001 - 18:27:52 CDT
Martin,
I'm afraid Andrew's right. In the past, I've spent a lot of time making
sure that the Win32 debug memory heap showed *zero* leaks on a simple
launch-and-exit scenario. I've just rebuilt a current view and now there are
a *ton* of small leaks in that scenario. Over a thousand, in fact. :-(
Unfortunately, most of the items leaked weren't created directly via
malloc/new, but were instead created via wrapper classes like UT_String,
UT_StringBuf, and PP_PropertyType, which makes them much harder to track
down and fix (unless your leak-detection tool captures full stack traces).
For example, at first glance, it looks like whoever did the tree-wide grand
mal rewrite to convert existing strings to UT_Strings may not have added the
necessary cleanup code in each instance to make sure that the UT_String
destructor got called as needed. From examining the contents of the leaked
items, it looks like all of the following portions of code need to be checked:
- preferences
- custom dictionary entries
- property names
- style names
And those are the easy ones. :-( Many of the other items leaked are either
empty or contain single characters and/or line noise, which means it'll be a
lot harder to track down the offending leaks.
Ick.
What leak detection tools are people using on other platforms to make sure
their code is leak-free?
Paul
This archive was generated by hypermail 2b25 : Tue Jun 19 2001 - 18:21:04 CDT