Unallocated memorz being freed in <iostream>?

[lars.uffmann]

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>.

Now the very last bugs I seem to be incapable of eliminating are:
- 0x000000000061f 460 Free 387310 was never alloc'd 0x2aaaab053b53
- 0x000000000061f 040 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 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.
What it boiled down to was that I took .cpp-files from the makefile one
after another, in order to identify the one causing the problem.
Eventually I had one, but there is no memory freed in there unless some
code is actually called and not just #included. I commented out lines
of code and whole functions, pasted #included files directly into the
..cpp to avoid the #include, and started commenting them out. 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.

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.

Any ideas?
Best Regards,
Lars

[Bernd Strieder]

Hello,

la**********@rw th-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:
- 0x000000000061f 460 Free 387310 was never alloc'd 0x2aaaab053b53
- 0x000000000061f 040 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