Hi Malte, > My concern here is: You do memory leak detection for *some* special > classes and don't find *other* leaks. > > Is this really what you want to do?
Usually, my UNO implementations are most prone (by far) to leaking, since it's pretty easy to have some cyclic references between two or more ref-counted instances. Thus, I'm most interested in finding leaks in those implementations, the more since a leak in a top-level UNO component usually means that dozens of other, dependent objects leak, too (in opposite to non-UNO classes leaking, which usually don't have that large tree of dependent leaking objects). Of course, all of this is completely unscientific and pure gut feeling :) > On Windows, you don't have to do specials builds just for finding memory > leaks. You can use free MS tools UMDH or LeakDiag, or commercial tools > like BoundsChecker. Well, the difference between freely deriving from a special class and using an expensive commercial tool should be clear :), so let's not talk about BoundsChecker. For the other tools: Where have they been announced, where can I read how to use them? > I am quite sure you don't have to do anything special on Linux, when > using Valgrind.... I'd say both approaches - using tools and using LeakGuard - make sense. The latter has the advantage that it can be done "by passing", provided that leaked objects are logged/dumped/whatever. QA may do normal tests and "by the way" also check the log file for leaked instances. That's not as comprehensive as using a tool (thus tools have the right to exist and to be used, too), but it has much lower entry hurdles. Can we perhaps agree on "Both approaches have the right to exist"? > With your suggested solution, you might see that some *special* objects > are leaking. > But then? > You can't use the debugger and follow all CTOR/DTOR calls, at least not > for mass objects. No, but for the single object in the object hierarchy which most probably caused a lot of the other leaks. Of course this requires experience - looking at the log, a developer could be able to tell which leak is the "primary" one and caused the others (simply because the primary object holds the others). I've done this before more than once (with the DBG_XTOR facilities), so please don't tell it cannot be done :) Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
