Michael wrote
but the advantage is that searching for hack_acquire in valgrind's output
very quickly finds the actual leak.
what is your analysis of why there is a leak in uno::Reference, and where
did you find it. Was your correction a small bit of?
On Tuesday 21 of October 2014, Noel Grandin wrote:
On 2014-10-20 06:27 PM, Michael Stahl wrote:
there are 2 ways i've tried to track down the 2 leaking acquire()s:
1. instrument the acquire()/release() method and run the test in gdb,
the script just takes 2 minutes to run (90 seconds of
On 2014-10-20 06:27 PM, Michael Stahl wrote:
there are 2 ways i've tried to track down the 2 leaking acquire()s:
1. instrument the acquire()/release() method and run the test in gdb,
the script just takes 2 minutes to run (90 seconds of which are spent in
a single regex) but unfortunately
On 21.10.2014 12:07, Noel Grandin wrote:
On 2014-10-20 06:27 PM, Michael Stahl wrote:
there are 2 ways i've tried to track down the 2 leaking acquire()s:
1. instrument the acquire()/release() method and run the test in gdb,
the script just takes 2 minutes to run (90 seconds of which are
On 10/21/2014 03:59 PM, Michael Stahl wrote:
possibly backtrace_symbols - but we do want to have de-mangled C++
function names, since the approach generally requires manual analysis
and you want to be able to quickly discard obviously wrongly detected leaks.
...just pipe the output through
Hi,
On Mon, Oct 20, 2014 at 06:27:42PM +0200, Michael Stahl wrote:
as everyone knows, C++ programs do not leak memory because they use RAII
and smart pointers to automatically release all allocated memory at just
the right time.
... but enough with the jocularities: there was this
On 21.10.2014 18:20, David Tardon wrote:
Hi,
On Mon, Oct 20, 2014 at 06:27:42PM +0200, Michael Stahl wrote:
as everyone knows, C++ programs do not leak memory because they use RAII
and smart pointers to automatically release all allocated memory at just
the right time.
... but enough
... but enough with the jocularities: there was this ChartModel that
was leaked due to a uno::Reference cycle, which means that the usual
tools like valgrind and address sanitizer aren't very useful as such.
I would expect
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all
as everyone knows, C++ programs do not leak memory because they use RAII
and smart pointers to automatically release all allocated memory at just
the right time.
... but enough with the jocularities: there was this ChartModel that was
leaked due to a uno::Reference cycle, which means that the
