proposal: rtl::LeakGuard

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

proposal: rtl::LeakGuard

Daniel Boelzle

Hello,

I'd like to present/discuss a recent helper, called rtl::LeakGuard which
helps to find leaking free store objects.  The helper works by embracing
the CRTP (curiously recurring template pattern), e.g. you use it like

class MyClass : private rtl::LeakGuard<MyClass> {...};

This creates static informtation about created and destructed MyClass
objects.
In non-pro builds, the LeakGuard OSL_ASSERTs any undestroyed (leaking)
objects while in product builds the LeakGuard class is just plain empty
(and does not hurt performance).

The LeakGuard class has three modes:
- LEAKGUARD_COUNT (default): just counts the number of instances
- LEAKGUARD_STORE_ADDRESSES: stores all addresses of created objects
[- LEAKGUARD_NONE: empty LeakGuard class for product builds]

LEAKGUARD_STORE_ADDRESSES has the advantage to iterate over all
instances using your debugger, but the disadvantage of using more memory.

You can explicitly switch the mode in your code, e.g.

class MyClass : private rtl::LeakGuard<MyClass,
                                       rtl::LEAKGUARD_STORE_ADDRESSES>

or override the default mode placing a

CDEFS += -DRTL_LEAKGUARD_DEFAULT_MODE=LEAKGUARD_STORE_ADDRESSES

in your makefile.pmk (or similar).

If you are interested in checking the current (static) object count of a
LeakGuard-ed class, you can do so by calling the (static) member function:

static bool checkObjectCount( ::std::size_t nExpected = 0 );

which asserts if the observed object count is not the expected.

You can have a look at the implementation on cws presfixes10 (tag
cws_src680_presfixes10):
sal/inc/rtl/leakguard.hxx

I have added the header to sal, because I think such a guard can be
useful for lots of code, also in very basic libraries.  IMO, there is
currently the problem, that headers of sal/cppu/etc will get a
(published into the concrete) part of the SDK.  So I have tagged all of
leakguard's inner definitions as @internal, thus nobody ought to rely on
it staying compatible.  We ought to expand the concept of
public/published API to the fields of C/C++/Java API, do we?
leakguard.hxx depends on e.g. osl/diagnose.h, so I can not put it into a
lower module than sal.

So what do you think?  Comments, please.

regards,
-Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Malte Timmermann
I like leak detection, but I think inheritance is not so useful here,
because you can't simply add leak detection to a class 'on demand',
without compiling all following modules.

We already have some leak detection in tools/debug.hxx:
DBG_CTOR and DBG_DTOR.
Together with DBG_CHECKTHIS, you can also use it to check if your object
is still valid.

Advantage: No inheritance
(Small) Disadvantage: Manually put DBG_CTOR/DTOR in all ctors and dtors.

So maybe you would like to extend the things we already have in tools...

Malte.

Daniel Boelzle wrote:

> Hello,
>
> I'd like to present/discuss a recent helper, called rtl::LeakGuard which
> helps to find leaking free store objects.  The helper works by embracing
> the CRTP (curiously recurring template pattern), e.g. you use it like
>
> class MyClass : private rtl::LeakGuard<MyClass> {...};
>
> This creates static informtation about created and destructed MyClass
> objects.
> In non-pro builds, the LeakGuard OSL_ASSERTs any undestroyed (leaking)
> objects while in product builds the LeakGuard class is just plain empty
> (and does not hurt performance).
>
> The LeakGuard class has three modes:
> - LEAKGUARD_COUNT (default): just counts the number of instances
> - LEAKGUARD_STORE_ADDRESSES: stores all addresses of created objects
> [- LEAKGUARD_NONE: empty LeakGuard class for product builds]
>
> LEAKGUARD_STORE_ADDRESSES has the advantage to iterate over all
> instances using your debugger, but the disadvantage of using more memory.
>
> You can explicitly switch the mode in your code, e.g.
>
> class MyClass : private rtl::LeakGuard<MyClass,
>                                        rtl::LEAKGUARD_STORE_ADDRESSES>
>
> or override the default mode placing a
>
> CDEFS += -DRTL_LEAKGUARD_DEFAULT_MODE=LEAKGUARD_STORE_ADDRESSES
>
> in your makefile.pmk (or similar).
>
> If you are interested in checking the current (static) object count of a
> LeakGuard-ed class, you can do so by calling the (static) member function:
>
> static bool checkObjectCount( ::std::size_t nExpected = 0 );
>
> which asserts if the observed object count is not the expected.
>
> You can have a look at the implementation on cws presfixes10 (tag
> cws_src680_presfixes10):
> sal/inc/rtl/leakguard.hxx
>
> I have added the header to sal, because I think such a guard can be
> useful for lots of code, also in very basic libraries.  IMO, there is
> currently the problem, that headers of sal/cppu/etc will get a
> (published into the concrete) part of the SDK.  So I have tagged all of
> leakguard's inner definitions as @internal, thus nobody ought to rely on
> it staying compatible.  We ought to expand the concept of
> public/published API to the fields of C/C++/Java API, do we?
> leakguard.hxx depends on e.g. osl/diagnose.h, so I can not put it into a
> lower module than sal.
>
> So what do you think?  Comments, please.
>
> regards,
> -Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Daniel Boelzle
In reply to this post by Daniel Boelzle

Hello Malte,

> I like leak detection, but I think inheritance is not so useful here,
> because you can't simply add leak detection to a class 'on demand',
> without compiling all following modules.

There is no need to recompile derived classes/modules, because the
LeakGuard-ed class references only static data and has no vtable.
Nevertheless, IMO leak detection has to be thoroughly considered during
programming, same as you add OSL_ASSERTs to your code, so there ought to
be little need for on-demand leak detection.

> We already have some leak detection in tools/debug.hxx:
> DBG_CTOR and DBG_DTOR.
> Together with DBG_CHECKTHIS, you can also use it to check if your object
> is still valid.
>
> Advantage: No inheritance
> (Small) Disadvantage: Manually put DBG_CTOR/DTOR in all ctors and dtors.
>

I really don't like macros, and IMO it is much more elegant to just
inherit the LeakGuard feature without thinking about constructors and
destructors.

> So maybe you would like to extend the things we already have in tools...

This would not solve the need for lower level modules, e.g. UDK modules.

regards,
-Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Thorsten Behrens
In reply to this post by Daniel Boelzle
Malte Timmermann <[hidden email]> writes:

> I like leak detection, but I think inheritance is not so useful here,
> because you can't simply add leak detection to a class 'on demand',
> without compiling all following modules.
>
> We already have some leak detection in tools/debug.hxx:
> DBG_CTOR and DBG_DTOR.
> Together with DBG_CHECKTHIS, you can also use it to check if your object
> is still valid.
>
> Advantage: No inheritance
> (Small) Disadvantage: Manually put DBG_CTOR/DTOR in all ctors and dtors.
>
Hi Malte,

in the world of namespaces, these macros look broken. Besides that,
having to manually put macros all over the place might be as big a
disadvantage as deriving privately (which is a single, isolated
modification) - IMHO, the latter is much less of a problem, because
the compiler does the work for you.

Cheers,

--

Thorsten

If you're not failing some of the time, you're not trying hard enough.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

frank.schoenheit
In reply to this post by Daniel Boelzle
Hi Daniel,

> I'd like to present/discuss a recent helper, called rtl::LeakGuard which
> helps to find leaking free store objects.

To cite Thorsten: Great stuff!

> In non-pro builds, the LeakGuard OSL_ASSERTs any undestroyed (leaking)
> objects while in product builds the LeakGuard class is just plain empty
> (and does not hurt performance).

Is there a canonic place where this is is OSL_ASSERTEd (application
shutdown), or do I always have to explicitly use checkObjectCount?

The already-mentioned tools-macros had some other cool feature, which I
could imagine here: Upon app shutdown, a list was written which
contained information about all classed equipped with the DBG_XTOR
macros, stating the number of objects created, destroyed, max.existing
at a time, and leaked. While probably only the latter information is
really useful, it might be interesting to have such detection
capabilities for the LeakGuard, too.
But well, perhaps this is an issue for the yet-to-come consolidation of
the TOOLS/OSL diagnostics.


Do you have any guestimations about the impact on runtime-performance
even in non-pros, if this would be extensively used?
I mean, I'm tempted to re-fit all my UNO implementations with this
class, and those alone would probably be several hundreth classes. If
everybody would be doing this - would we have a problem in non-pros?

For the again-already-mentioned DBG_-tools, there was a rule to use them
only when needed, because else there *would* have been a problem.
Perhaps today, this is not the case anymore ...


> I have added the header to sal, because I think such a guard can be
> useful for lots of code, also in very basic libraries.

Definately yes. If the diagnostics-consolidation is ever going to
happen, and if we have a mature set of full-fledged diagnostic tools in
OSL then, I'd appreciate this class being moved to OSL, too.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Daniel Boelzle
In reply to this post by Daniel Boelzle

Hello Frank,

> Is there a canonic place where this is is OSL_ASSERTEd (application
> shutdown), or do I always have to explicitly use checkObjectCount?

There is only inline code, the LeakGuard references static data
(rtl::Static), which OSL_ASSERTs upon shutdown (assuming _all_ objects
are destructed).  I have added checkObjectCount() to check at runtime
how many objects are expected to be alive.

> The already-mentioned tools-macros had some other cool feature, which I
> could imagine here: Upon app shutdown, a list was written which
> contained information about all classed equipped with the DBG_XTOR
> macros, stating the number of objects created, destroyed, max.existing
> at a time, and leaked. While probably only the latter information is
> really useful, it might be interesting to have such detection
> capabilities for the LeakGuard, too.
> But well, perhaps this is an issue for the yet-to-come consolidation of
> the TOOLS/OSL diagnostics.

IMO it is better to separate those statistics into another class, so the
purpose of LeakGuard remains clear: finding leaks, not doing statistics.

> Do you have any guestimations about the impact on runtime-performance
> even in non-pros, if this would be extensively used?

Default is just counting (which comes down to an extra
osl_incrementInterlockedCount()/osl_decrementInterlockedCount()
for every object creation/destruction), so I _assume_ in general this
does not hurt.  When storing addresses, this is different; I use a
std::hash_set and a osl::Mutex to serialize accesses.

> I mean, I'm tempted to re-fit all my UNO implementations with this
> class, and those alone would probably be several hundreth classes. If
> everybody would be doing this - would we have a problem in non-pros?

Of course, nobody can answere this for sure.

>>I have added the header to sal, because I think such a guard can be
>>useful for lots of code, also in very basic libraries.
>
>
> Definately yes. If the diagnostics-consolidation is ever going to
> happen, and if we have a mature set of full-fledged diagnostic tools in
> OSL then, I'd appreciate this class being moved to OSL, too.

Why osl?  IMO rtl is the right place for this.  One could think of
salhelper (because of the C++ notion), but then we cannot use this in sal...

regards,
-Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

frank.schoenheit
Hi Daniel,

> IMO it is better to separate those statistics into another class, so the
> purpose of LeakGuard remains clear: finding leaks, not doing statistics.

Well, at least the last point of the statistics (the only one I ever
used: the number of leaked objects) serves exactly this purpose. It
would, for instance, enabled QA to regularily do leak tests on certain
usage scenarios.

>>Definately yes. If the diagnostics-consolidation is ever going to
>>happen, and if we have a mature set of full-fledged diagnostic tools in
>>OSL then, I'd appreciate this class being moved to OSL, too.
>
> Why osl?  IMO rtl is the right place for this.  One could think of
> salhelper (because of the C++ notion), but then we cannot use this in sal...

Uhm, don't really care. Just assumed OSL because I think it could be
part of a "diagnostics framework", and today's diagnostics are in OSL.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Malte Timmermann
In reply to this post by Daniel Boelzle
We should talk about the LeakGuard when consolidating the debug macros,
as Frank suggested.

Please don't introduce before.

I also suggest to have a macro for it, which simply expands to nothing
in product builds.

If we do anything in this direction, I think it shouldn't be only leak
detection, but statistics and logging too.

For leak detection, there are enough tools which don't require any code
changes.

We already fixed a lot of memory leaks for 2.0.1 with this tools, which
means that
- it's possible
- it's more easy now, because not so many leaks are reported
- you find them for all objects, not only for special objects

Malte.

Frank Sch?nheit - Sun Microsystems Germany wrote:

> Hi Daniel,
>
>
>>IMO it is better to separate those statistics into another class, so the
>>purpose of LeakGuard remains clear: finding leaks, not doing statistics.
>
>
> Well, at least the last point of the statistics (the only one I ever
> used: the number of leaked objects) serves exactly this purpose. It
> would, for instance, enabled QA to regularily do leak tests on certain
> usage scenarios.
>
>
>>>Definately yes. If the diagnostics-consolidation is ever going to
>>>happen, and if we have a mature set of full-fledged diagnostic tools in
>>>OSL then, I'd appreciate this class being moved to OSL, too.
>>
>>Why osl?  IMO rtl is the right place for this.  One could think of
>>salhelper (because of the C++ notion), but then we cannot use this in sal...
>
>
> Uhm, don't really care. Just assumed OSL because I think it could be
> part of a "diagnostics framework", and today's diagnostics are in OSL.
>
> Ciao
> Frank
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Daniel Boelzle
In reply to this post by Daniel Boelzle
Hello Frank,

>>IMO it is better to separate those statistics into another class, so the
>>purpose of LeakGuard remains clear: finding leaks, not doing statistics.
>
>
> Well, at least the last point of the statistics (the only one I ever
> used: the number of leaked objects) serves exactly this purpose. It
> would, for instance, enabled QA to regularily do leak tests on certain
> usage scenarios.

LeakGuard OSL_ASSERTs if the object count is non-zero upon process
shutdown.  IMO statistics like "how many objects have been created,
destructed" ought to be shifted into another diagnostics class, keeping
the purpose of LeakGuard clear.

>>>Definately yes. If the diagnostics-consolidation is ever going to
>>>happen, and if we have a mature set of full-fledged diagnostic tools in
>>>OSL then, I'd appreciate this class being moved to OSL, too.
>>
>>Why osl?  IMO rtl is the right place for this.  One could think of
>>salhelper (because of the C++ notion), but then we cannot use this in sal...
>
>
> Uhm, don't really care. Just assumed OSL because I think it could be
> part of a "diagnostics framework", and today's diagnostics are in OSL.

Good point.  So LeakGuard ought to be in osl/diagnose.hxx?

And what about a different name?

class C : private osl::leak_guarded<C> {...};

regards,
-Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

frank.schoenheit
Hi Daniel,

>>Well, at least the last point of the statistics (the only one I ever
>>used: the number of leaked objects) serves exactly this purpose. It
>>would, for instance, enabled QA to regularily do leak tests on certain
>>usage scenarios.
>
> LeakGuard OSL_ASSERTs if the object count is non-zero upon process
> shutdown.  IMO statistics like "how many objects have been created,
> destructed" ought to be shifted into another diagnostics class, keeping
> the purpose of LeakGuard clear.

Ehm, yes - that's what I tried to say. I agree that the semantics of the
LeakGuard should be kept clear and straight-forward. But this so far
doesn't disallow doing shutdown-time statistics of *leaked instances*,
does it? Everything else (instances created and the like) is indeed not
in the scope of a LeakGuard.

>>Uhm, don't really care. Just assumed OSL because I think it could be
>>part of a "diagnostics framework", and today's diagnostics are in OSL.
>
> Good point.  So LeakGuard ought to be in osl/diagnose.hxx?

let's not put too much into a single file ...
If we agree that Leakguard is a diagnose tool like OSL_*, then it should
be in module osl (or in the same module as later, new, diagnostics
helpers), too. Else, I don't really care whether osl or rtl ...

> And what about a different name?
>
> class C : private osl::leak_guarded<C> {...};

Don't have an opinion on this ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

frank.schoenheit
In reply to this post by Malte Timmermann
Hi Malte,

> We should talk about the LeakGuard when consolidating the debug macros,
> as Frank suggested.
>
> Please don't introduce before.

Uh. Let's not wait for something which perhaps happens in 2007.
Introduce it when it's there, and when it's needed: now.

> I also suggest to have a macro for it, which simply expands to nothing
> in product builds.

Why? The solution to derive from this class seems pretty elegant to me,
I don't see a need for a macro here.

> If we do anything in this direction, I think it shouldn't be only leak
> detection, but statistics and logging too.

I have to agree to Daniel here that we perhaps shouldn't necessarily mix
*all* this into *one* class. A LeakGuard should be about leak detection.
IMO, this includes statistics about leaked objects, but excludes
statistics about instance counts or so.

> For leak detection, there are enough tools which don't require any code
> changes.

But they require code instrumentation, don't they?
I like the idea of having a tool which is enabled in non-product builds
*by default*, enabling *everybody* (including QA) to check for leaks
without any additional effort.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

frank.schoenheit
In reply to this post by Malte Timmermann
Hi Malte,

> We should talk about the LeakGuard when consolidating the debug macros,
> as Frank suggested.
>
> Please don't introduce before.

Uh. Let's not wait for something which perhaps happens in 2007.
Introduce it when it's there, and when it's needed: now.

> I also suggest to have a macro for it, which simply expands to nothing
> in product builds.

Why? The solution to derive from this class seems pretty elegant to me,
I don't see a need for a macro here.

> If we do anything in this direction, I think it shouldn't be only leak
> detection, but statistics and logging too.

I have to agree to Daniel here that we perhaps shouldn't necessarily mix
*all* this into *one* class. A LeakGuard should be about leak detection.
IMO, this includes statistics about leaked objects, but excludes
statistics about instance counts or so.

> For leak detection, there are enough tools which don't require any code
> changes.

But they require code instrumentation, don't they?
I like the idea of having a tool which is enabled in non-product builds
*by default*, enabling *everybody* (including QA) to check for leaks
without any additional effort.

Ciao
Frank

PS: please don't reply-all when reading/writing via a newsgroup-gateway.
This results in your message being duplicated in the mailing list. Thanks.

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Malte Timmermann
In reply to this post by Daniel Boelzle
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?

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.

I am quite sure you don't have to do anything special on Linux, when
using Valgrind....

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.

Your solution will not provide stacktraces (point of allocation) for
objects which where not freed.
External tools will do so.

Malte.


Frank Sch?nheit wrote:

> Hi Malte,
>
>
>>We should talk about the LeakGuard when consolidating the debug macros,
>>as Frank suggested.
>>
>>Please don't introduce before.
>
>
> Uh. Let's not wait for something which perhaps happens in 2007.
> Introduce it when it's there, and when it's needed: now.
>
>
>>I also suggest to have a macro for it, which simply expands to nothing
>>in product builds.
>
>
> Why? The solution to derive from this class seems pretty elegant to me,
> I don't see a need for a macro here.
>
>
>>If we do anything in this direction, I think it shouldn't be only leak
>>detection, but statistics and logging too.
>
>
> I have to agree to Daniel here that we perhaps shouldn't necessarily mix
> *all* this into *one* class. A LeakGuard should be about leak detection.
> IMO, this includes statistics about leaked objects, but excludes
> statistics about instance counts or so.
>
>
>>For leak detection, there are enough tools which don't require any code
>>changes.
>
>
> But they require code instrumentation, don't they?
> I like the idea of having a tool which is enabled in non-product builds
> *by default*, enabling *everybody* (including QA) to check for leaks
> without any additional effort.
>
> Ciao
> Frank
>
> PS: please don't reply-all when reading/writing via a newsgroup-gateway.
> This results in your message being duplicated in the mailing list. Thanks.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

frank.schoenheit
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal: rtl::LeakGuard

Daniel Boelzle
In reply to this post by Daniel Boelzle

Hello,

talking offline here in Hamburg, we agreed that it makes sense to add
such a class.  Special tests with external tools (valgrind,
BoundsChecker) are valuable, but may not cover a problematic program
path leading to leaks, because those tests are most often run by
developers.  Using the proposed class gives easy indication that
something goes wrong in every nonpro build, like OSL_ASSERTs do.

We agreed to shift the existing checking/statistics facilities from
tools into that class (which is future work), so there will be only one
consolidated API.
For the moment
- the class will be an unpublished API in osl/diagnose.hxx, that may
change in the future
- the name will change to DebugBase (reflecting that it (potentially)
does more than just leak checking, e.g. storing construction stack
traces, counting statistics)

Did I forget anything?

regards,
-Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]