help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unallocated memorz being freed in <iostream>?


From: Bernd Strieder
Subject: Re: Unallocated memorz being freed in <iostream>?
Date: Wed, 23 Aug 2006 18:03:12 +0200
User-agent: KNode/0.10.1

Hello,

lars.uffmann@rwth-aachen.de wrote:

> Hello everyone!
> 
> I just debugged a pretty huge project, eliminating basically every
> memory leak that would occur with the current configuration files, at
> least according to the mtrace() tool from the library <mcheck.h>.

This is a bit off-topic here. The particular problem only visible on GNU
platforms. I will answer, nevertheless, because similar problems might
be observable on any problem. Another memory debugging tool considered
worth looking at is valgrind. There is also purify.

> 
> Now the very last bugs I seem to be incapable of eliminating are:
> - 0x000000000061f460 Free 387310 was never alloc'd 0x2aaaab053b53
> - 0x000000000061f040 Free 387311 was never alloc'd 0x2aaaab053b53
> 
> Or, if I exit from the main function right after startig mtrace (as
> below), those become Free 2 and Free 3.
> 
> #include <iostream>
> #include <mcheck.h>
> 
> int main (int argc, char** argv) {
>   mtrace();
> exit(0);
> }
> 

If mtrace turns tracing on, then allocations done before might not have
been traced, or falsely classified, if the free gets traced, but not
the allocation. This is a frequent problem with false positives by
malloc debugging facilities. The C++ streams cin, cout, ... are global
objects which are instantiated before the body of main is executed. And
they will allocate memory.

> If I compile that program with g++ -o a.out a.cpp then everything runs
> fine without unallocated memory freeings, however if I use my makefile
> which has a bunch of sourcecode-files in it, then I get those 2
> unallocated but freed pointers.

The compiler/linker might be able to remove unneccessary cin/cout
objects, if no translation unit needs it.

> It all ended with the only line left being #include <iostream>.
> If I take that out, the program runs with no memory problems according
> to mtrace(). As soon as I put it back in, the 2 unallocated but freed
> pointers are back.

IOW, More indications towards cin/cout...

> 
> I am suspecting a bug in my software rather than in iostream because I
> cannot reproduce this behaviour in a very small test environment. But
> still, I can not exclude the possibility that there is a bug in
> iostream and furthermore I have no clue on how to further try to
> pinpoint the actual bug.

No bug in software, but bug in user. You make mtrace produce false
positives.

Bernd Strieder



reply via email to

[Prev in Thread] Current Thread [Next in Thread]