From: Nile Aagard <inventerna@gmail.com>
To: binutils@sourceware.org
Subject: Random memory leak in binutils?
Date: Wed, 10 Feb 2021 13:00:31 -0700 [thread overview]
Message-ID: <5f1fce90-15c7-299c-6edc-6eb77dd90792@gmail.com> (raw)
I've just discovered valgrind and have been using it to check for memory
leaks in a project I've been working on.
But something strange happened that I have just finished proving is
related to the GCC profiler: without the argument (`-pg') I get 22
allocs and 22 frees, but with the argument I tend to get 23 allocs and
22 frees with a fallout of a little more than 16KB as shown in the
report below:
$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all
./test.brainbytes
==20624== Memcheck, a memory error detector
==20624== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward
et al.
==20624== Using Valgrind-3.16.1 and LibVEX; rerun with -h for
copyright info
==20624== Command: ./test.brainbytes
==20624==
[Core] Initialize & Destroy: FAILED
- [Init] Memory Stack is wrong size.
- [Init] Function Stack wrong size.
- [Init] Operator List wrong size.
- [Init] Thread Tracker wrong size.
==20624==
==20624== Process terminating with default action of signal 27
(SIGPROF)
==20624== at 0x4CA026A: __open_nocancel (in /usr/lib/libc-2.33.so)
==20624== by 0x4CAC4FF: write_gmon (in /usr/lib/libc-2.33.so)
==20624== by 0x4CACCBE: _mcleanup (in /usr/lib/libc-2.33.so)
==20624== by 0x4BEAC8D: __cxa_finalize (in /usr/lib/libc-2.33.so)
==20624== by 0x109247: ??? (in /srv/http/build/test.brainbytes)
==20624== by 0x401023A: _dl_fini (in /usr/lib/ld-2.33.so)
==20624== by 0x4BEA696: __run_exit_handlers (in
/usr/lib/libc-2.33.so)
==20624== by 0x4BEA83D: exit (in /usr/lib/libc-2.33.so)
==20624== by 0x4BD2B2B: (below main) (in /usr/lib/libc-2.33.so)
==20624==
==20624== HEAP SUMMARY:
==20624== in use at exit: 16,818 bytes in 1 blocks
==20624== total heap usage: 23 allocs, 22 frees, 95,250 bytes
allocated
==20624==
==20624== 16,818 bytes in 1 blocks are still reachable in loss
record 1 of 1
==20624== at 0x4840B65: calloc (vg_replace_malloc.c:760)
==20624== by 0x4CACAF2: monstartup (in /usr/lib/libc-2.33.so)
==20624== by 0x109180: __gmon_start__ (in
/srv/http/build/test.brainbytes)
==20624== by 0x483E015: ??? (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20624== by 0x1FFF0007DF: ???
==20624== by 0x400FE49: call_init.part.0 (in /usr/lib/ld-2.33.so)
==20624== by 0x4010008: _dl_init (in /usr/lib/ld-2.33.so)
==20624== by 0x40010C9: ??? (in /usr/lib/ld-2.33.so)
==20624==
==20624== LEAK SUMMARY:
==20624== definitely lost: 0 bytes in 0 blocks
==20624== indirectly lost: 0 bytes in 0 blocks
==20624== possibly lost: 0 bytes in 0 blocks
==20624== still reachable: 16,818 bytes in 1 blocks
==20624== suppressed: 0 bytes in 0 blocks
==20624==
==20624== For lists of detected and suppressed errors, rerun with: -s
==20624== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0
from 0)
Profiling timer expired
NOTE that all lines from valgrind are prefixed by "==20624==" and
application output is not prefixed, making the most important messages
the two callstacks from valgrind and the final message from the profiler.
The strange component to all this is that that every few runs this leak
does not occur and I get 23 frees like there's supposed to be.
By removing the offending argument `-pg' from by compiler and linker
this issue goes away which verifies to me that the issue is not in my
code; there's nothing special about my code either, I am only using the
default libraries.
I don't know exactly where the issue occurs being unfamiliar with ld and
libc internals, or if the problem is simply the result of a disagreement
between the profiler and valgrind which is why I dare not file it as a
bug report.
What I do know is that memory leaks are undesirable, like rebuilding
with different parameters between tests.
Perhaps you could shed some light on the subject? Has there been a
previous case that concluded with the profiler and valgrind just aren't
designed to work together? Or is this a "new" issue that has not been
previously seen?
In any case I appreciate your consideration of this matter, as well as
your patience with my ignorance.
In total sincerity,
Nile Aagard
next reply other threads:[~2021-02-10 20:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 20:00 Nile Aagard [this message]
2021-02-26 14:37 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f1fce90-15c7-299c-6edc-6eb77dd90792@gmail.com \
--to=inventerna@gmail.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).