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:
- 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 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,

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