Memleak in commentator

[Clement Pernet]

I have tried several attempts to fix a memleak in
linbox/util/commentator.h:740

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

[B.David Saunders]

The static commentator is not in the scope of any function, including
main(), so I think this is not really a memleak.

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.

-dave

[Clement Pernet]

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?

Clément

[mabshoff]

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

[Clement Pernet]

Hi Michael,

I am currently trying to polishing everything in order to release
1.1.5.
I have put several commits on svn fixing uninitialized memory issues,
so maybe that fixed your bugs.
However, can you send them, and I'll check that.

I hope to have a release candidate before the end of the day. I have a
tarball running pretty smoothly on IA64, AMD64, PPC, and PIII32, but I
still didn't checked all extra lib configurations.

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.

Clément
On Feb 20, 4:41 pm, mabshoff <Michael.Absh...@fsmath.mathematik.uni-

[mabshoff]

On Feb 21, 2:19 am, Clement Pernet <clement.per...@gmail.com> wrote:
> Hi Michael,

Hi Clément,

> I am currently trying to polishing everything in order to release
> 1.1.5.
> I have put several commits on svn fixing uninitialized memory issues,
> so maybe that fixed your bugs.
> However, can you send them, and I'll check that.

I have nothing ready to go and am currently working on the Sage 2.10.2
release.

> I hope to have a release candidate before the end of the day. I have a
> tarball running pretty smoothly on IA64, AMD64, PPC, and PIII32, but I
> still didn't checked all extra lib configurations.
>
> 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.

Ok, we found another problem in Givaro that causes segfaults on 32 bit
boxen due to uninitialized memory. It is independent of LinBox. I will
be poking around there with memcheck as well as omega and I might also
track down the LinBox+Givaro leak that way. But I will only get around
to it on Friday. Hopefully we can then also get all Sage patches of
Givaro up into 3.2.9 or whatever the current version is. But we can
discuss all that in #sage-devel on Friday or so.

I still have those two inline patches by Stefan Kaspar that ought to
go into 1.1.5. Let me dig them out and send to you offlist.

> Clément
<SNIP>

Cheers,

Michael