> Valgrinding any linbox executable (compiled with -DDISABLE_COMMENTATOR)
> as follows

> valgrind --leak-check=full --show-reachable=yes examples/det A

> leads to the following (and not unique) memleak
> ==22904== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==22904==    at 0x4023294: operator new(unsigned) (vg_replace_malloc.c:224)
> ==22904==    by 0x805CE7E:
> LinBox::CommentatorDisabled::CommentatorDisabled() (commentator.h:740)
> ==22904==    by 0x804C6AE:
> __static_initialization_and_destruction_0(int, int) (commentator.h:816)
> ==22904==    by 0x804C6EE: _GLOBAL__I__ZN7Integer4zeroE (det.C:81)
> ==22904==    by 0x80EF80A: (within /usr/local/algebra/linbox/examples/det)
> ==22904==    by 0x804AAF3: (within /usr/local/algebra/linbox/examples/det)
> ==22904==    by 0x80EF7A8: __libc_csu_init (in
> /usr/local/algebra/linbox/examples/det)
> ==22904==    by 0x41ABFF0: (below main) (in
> /lib/tls/i686/cmov/libc-2.6.1.so)

> The commentator makes a new nullstreambuf() but never delete it.

> I have added the missing destructor in the class nullstreambu,
> explicitly destroyed the cnull in the destructor of commentator (taking
> away the virtual). Nothing changes.

> This comes apparently from the static instantiation of the commentator
> object (commentator.h:815), but I can't find a way to fix it.

> JG, Pascal, whoever has any idea, help!

> Clément

> Yes it is in the scope of many functions:
> comment the instantiation at commentator.h:816 and try to compile
> examples/det for example

> first occurrence is at randiter/modular.h:94

> But I agree, it is not a leak but just a memory never deleted and still
> reachable, which is less troublesome but still not great.> I would like the disabled commentator to have even lighter footprint -
> > zero memory and time use.  I would be interested to know whether the
> > calls to that nullstreambuf such as "report << something" completely
> > vanish in compiled code or are costing overhead.

> Could someone with a good understanding of the commentator class try to
> fix it?
> Moreover, I think everyone is using -DDISABLE_COMMENTATOR, since the
> real one is broken.
> Any volunteer to fix it?

> > B.David Saunders a écrit :> The static commentator is not in the scope of any function, including
> > > main(), so I think this is not really a memleak.

> > Yes it is in the scope of many functions:
> > comment the instantiation at commentator.h:816 and try to compile
> > examples/det for example

> > first occurrence is at randiter/modular.h:94

> > But I agree, it is not a leak but just a memory never deleted and still
> > reachable, which is less troublesome but still not great.> I would like the disabled commentator to have even lighter footprint -
> > > zero memory and time use.  I would be interested to know whether the
> > > calls to that nullstreambuf such as "report << something" completely
> > > vanish in compiled code or are costing overhead.

> > Could someone with a good understanding of the commentator class try to
> > fix it?
> > Moreover, I think everyone is using -DDISABLE_COMMENTATOR, since the
> > real one is broken.
> > Any volunteer to fix it?

> The above leak might actually be one of the few cases where valgrind
> prints a false positive report. The data is static, so it is a corner
> case anyway. If you can rewrite the commentator to get rid of the
> issue do so, but I got a couple other "uninitialized memory" bugs that
> valgrind turns up if anyone is looking for work to do :)

> > Clément

> Cheers,

> Michael

> Coming back to the memleak in commentator, I won't address it in
> 1.1.5, neither the givaro/charpoly related ones, as I told you at SD7.