Valgrind shows memory leak with empty main without including headers - c++

Lubuntu 15.10
I have project with memory leaks. I can find them, so I cleaned up my main.cpp file, and now it looks like this:
int main()
{
return 0;
}
When I check memory with the command:
valgrind --leak-check=full --show-leak-kinds=all ./MyProgram > log1.txt 2>&1
I got these errors:
==5219==
==5219== LEAK SUMMARY:
==5219== definitely lost: 0 bytes in 0 blocks
==5219== indirectly lost: 0 bytes in 0 blocks
==5219== possibly lost: 728 bytes in 18 blocks
==5219== still reachable: 44,676 bytes in 224 blocks
==5219== of which reachable via heuristic:
==5219== newarray : 832 bytes in 16 blocks
==5219== suppressed: 0 bytes in 0 blocks
==5219==
==5219== For counts of detected and suppressed errors, rerun with: -v
==5219== ERROR SUMMARY: 18 errors from 18 contexts (suppressed: 0 from 0)
Some of the errors were:
==5219== 2,048 bytes in 1 blocks are still reachable in loss record 240 of 242
==5219== at 0x402E2EC: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5219== by 0x5F7C151: g_realloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.4600.2)
==5219== by 0x5F06BCB: g_value_register_transform_func (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5F08D6A: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5ED9A2D: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x400EDCF: call_init.part.0 (dl-init.c:72)
==5219== by 0x400EEDF: call_init (dl-init.c:30)
==5219== by 0x400EEDF: _dl_init (dl-init.c:120)
==5219== by 0x4000ACE: ??? (in /lib/i386-linux-gnu/ld-2.21.so)
==5219== 8 bytes in 1 blocks are possibly lost in loss record 95 of 242
==5219== at 0x402E0D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5219== by 0x5F7C0DA: g_malloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.4600.2)
==5219== by 0x5EFC587: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5F011B8: g_type_register_fundamental (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5EE929E: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5ED9A1E: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x400EDCF: call_init.part.0 (dl-init.c:72)
==5219== by 0x400EEDF: call_init (dl-init.c:30)
==5219== by 0x400EEDF: _dl_init (dl-init.c:120)
==5219== by 0x4000ACE: ??? (in /lib/i386-linux-gnu/ld-2.21.so)
Full log file: http://pastebin.com/DQxQtnzK
How do I solve this problem? What should I do?

The leaks are not from your code
Transcribing comments with minimal editing.
Add suppressions; they're 'leaks' caused by the startup code that can't be fixed by you and probably won't be fixed by the developers of the C++ runtime. This is an extensive problem on Mac OS X. There are typically many allocations and a few tens of kilobytes of memory that are allocated by the startup code. (Options include --gen-suppressions=all and --suppressions=suppressions-file.)
This collected the comment:
FATAL: can't open suppressions file "suppressions-file"
Which got the riposte (since I was under time pressure when I made the comment):
Read the manual. You use --gen-suppressions=all to generate the suppressions […]. Then edit the file (there's a placeholder where you're supposed to put an ID/name for each suppression entry). Then you can use the file in subsequent runs with --suppressions=name-you-created. You may need --show-leak-kinds=all, and maybe some others, too (-leak-check=full, for example). Use valgrind --help, but be aware that the output is fairly extensive.
Worked example — Mac OS X 10.11.4
Source (mincpp.cpp)
int main() { return 0; }
Compilation
g++ -O3 -g -std=c++11 mincpp.cpp -o mincpp
(I normally use many more warning options, but with this code, there's really no need.)
Initial run with valgrind
$ valgrind mincpp
==69167== Memcheck, a memory error detector
==69167== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==69167== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==69167== Command: mincpp
==69167==
--69167-- UNKNOWN fcntl 97!
--69167-- UNKNOWN fcntl 97! (repeated 2 times)
--69167-- UNKNOWN fcntl 97! (repeated 4 times)
--69167-- UNKNOWN fcntl 97! (repeated 8 times)
--69167-- UNKNOWN fcntl 97! (repeated 16 times)
--69167-- UNKNOWN fcntl 97! (repeated 32 times)
==69167==
==69167== HEAP SUMMARY:
==69167== in use at exit: 22,195 bytes in 190 blocks
==69167== total heap usage: 255 allocs, 65 frees, 27,947 bytes allocated
==69167==
==69167== LEAK SUMMARY:
==69167== definitely lost: 4,120 bytes in 2 blocks
==69167== indirectly lost: 2,288 bytes in 6 blocks
==69167== possibly lost: 4,880 bytes in 45 blocks
==69167== still reachable: 2,344 bytes in 12 blocks
==69167== suppressed: 8,563 bytes in 125 blocks
==69167== Rerun with --leak-check=full to see details of leaked memory
==69167==
==69167== For counts of detected and suppressed errors, rerun with: -v
==69167== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
That's a lot of leakage for such a minimal program!
The unknown fcntl messages are a nuisance but appear to be 'mostly harmless'; I probably need to rebuild valgrind once more.
Generate suppressions
$ valgrind --gen-suppressions=all --leak-check=full --show-leak-kinds=all mincpp
==69211== Memcheck, a memory error detector
==69211== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==69211== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==69211== Command: mincpp
==69211==
--69211-- UNKNOWN fcntl 97!
--69211-- UNKNOWN fcntl 97! (repeated 2 times)
--69211-- UNKNOWN fcntl 97! (repeated 4 times)
--69211-- UNKNOWN fcntl 97! (repeated 8 times)
--69211-- UNKNOWN fcntl 97! (repeated 16 times)
--69211-- UNKNOWN fcntl 97! (repeated 32 times)
==69211==
==69211== HEAP SUMMARY:
==69211== in use at exit: 22,195 bytes in 190 blocks
==69211== total heap usage: 255 allocs, 65 frees, 27,947 bytes allocated
==69211==
==69211== 24 bytes in 1 blocks are still reachable in loss record 5 of 62
==69211== at 0x1000071FC: malloc_zone_malloc (vg_replace_malloc.c:304)
==69211== by 0x1005DC1E4: _read_images (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005E19EB: object_setClass (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DABC7: gc_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DA8C1: preopt_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DA5CA: map_images_nolock (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005ECC6C: batchFinalizeOnTwoThreads(_malloc_zone_t*, void (*)(auto_zone_cursor*, void (*)(void*, void*), void*), auto_zone_cursor*, unsigned long) (in /usr/lib/libobjc.A.dylib)
==69211== by 0x7FFF5FC047CF: dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x7FFF5FC04516: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x10023789D: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==69211== by 0x1005D907B: _objc_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1001DFC93: _os_object_init (in /usr/lib/system/libdispatch.dylib)
==69211==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:gc_init
fun:preopt_init
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
==69211== 24 bytes in 1 blocks are still reachable in loss record 6 of 62
==69211== at 0x1000071FC: malloc_zone_malloc (vg_replace_malloc.c:304)
==69211== by 0x1005DC1E4: _read_images (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005E19EB: object_setClass (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DCC96: NXHashInsert (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DB9B8: _read_images (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DA5DA: map_images_nolock (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005ECC6C: batchFinalizeOnTwoThreads(_malloc_zone_t*, void (*)(auto_zone_cursor*, void (*)(void*, void*), void*), auto_zone_cursor*, unsigned long) (in /usr/lib/libobjc.A.dylib)
==69211== by 0x7FFF5FC047CF: dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x7FFF5FC04516: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x10023789D: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==69211== by 0x1005D907B: _objc_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1001DFC93: _os_object_init (in /usr/lib/system/libdispatch.dylib)
==69211==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:NXHashInsert
fun:_read_images
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
…
==69211== LEAK SUMMARY:
==69211== definitely lost: 4,120 bytes in 2 blocks
==69211== indirectly lost: 2,288 bytes in 6 blocks
==69211== possibly lost: 4,880 bytes in 45 blocks
==69211== still reachable: 2,344 bytes in 12 blocks
==69211== suppressed: 8,563 bytes in 125 blocks
==69211==
==69211== For counts of detected and suppressed errors, rerun with: -v
==69211== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 12 from 12)
$
Sometimes, I add --num-callers=NN for some number NN, but the default seems to be 12 on my build (it was less in earlier versions, I think), which is adequate.
Generate suppressions in file min.suppressions
$ valgrind --gen-suppressions=all --leak-check=full --show-leak-kinds=all mincpp 2>./min.suppressions
$
Edit min.suppressions
Delete lines starting == and --; what's left are suppressions. Add names for the suppressions. End result is similar to:
{
Mac-OSX-10.11.4-GCC-5.3.0-C++-Suppressions-001
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:gc_init
fun:preopt_init
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
{
Mac-OSX-10.11.4-GCC-5.3.0-C++-Suppressions-002
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:NXHashInsert
fun:_read_images
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
…
{
Mac-OSX-10.11.4-GCC-5.3.0-C++-Suppressions-021
Memcheck:Leak
match-leak-kinds: definite
fun:malloc_zone_memalign
fun:_ZL11addSubclassP10objc_classS0_
fun:_ZL12realizeClassP10objc_class
fun:_ZL12realizeClassP10objc_class
fun:_ZN4dyldL12notifySingleE17dyld_image_statesPK11ImageLoader
fun:_ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListERNS_15UninitedUpwardsE
fun:_ZN11ImageLoader19processInitializersERKNS_11LinkContextEjRNS_21InitializerTimingListERNS_15UninitedUpwardsE
fun:_ZN11ImageLoader19processInitializersERKNS_11LinkContextEjRNS_21InitializerTimingListERNS_15UninitedUpwardsE
fun:_ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
fun:_ZN4dyld24initializeMainExecutableEv
fun:_ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm
fun:_ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm
}
Rerun with --suppressions=./min.suppressions
$ valgrind --suppressions=./min.suppressions mincpp
==72028== Memcheck, a memory error detector
==72028== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==72028== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==72028== Command: mincpp
==72028==
--72028-- UNKNOWN fcntl 97!
--72028-- UNKNOWN fcntl 97! (repeated 2 times)
--72028-- UNKNOWN fcntl 97! (repeated 4 times)
--72028-- UNKNOWN fcntl 97! (repeated 8 times)
--72028-- UNKNOWN fcntl 97! (repeated 16 times)
--72028-- UNKNOWN fcntl 97! (repeated 32 times)
==72028==
==72028== HEAP SUMMARY:
==72028== in use at exit: 22,195 bytes in 190 blocks
==72028== total heap usage: 255 allocs, 65 frees, 27,947 bytes allocated
==72028==
==72028== LEAK SUMMARY:
==72028== definitely lost: 0 bytes in 0 blocks
==72028== indirectly lost: 0 bytes in 0 blocks
==72028== possibly lost: 0 bytes in 0 blocks
==72028== still reachable: 0 bytes in 0 blocks
==72028== suppressed: 22,195 bytes in 190 blocks
==72028==
==72028== For counts of detected and suppressed errors, rerun with: -v
==72028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
This shows that the previously reported errors are now suppressed.

Related

Valgrind reports memory leak related with CRYPTO_zalloc in a c++ app but no additional info

I've created a c++ app in an arm embedded board .The board uses armbian linux debian flavour. This app in several places execute https request with the help of poco NetSSl library.
When I run the valgrind with the following arguments:
valgrind --leak-check=full --leak-resolution=high --show-reachable=yes --num-callers=20 --track-origins=yes --show-below-main=yes --log-file=valrgind.log ./c++_app
I get the following error message :
==2414== Memcheck, a memory error detector
==2414== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2414== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2414== Command: ./c++_app
==2414== Parent PID: 1556
==2414==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==2414== valgrind: Unrecognised instruction at address 0x52a17e7.
==2414== at 0x52A17E6: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Your program just tried to execute an instruction that Valgrind
==2414== did not recognise. There are two possible reasons for this.
==2414== 1. Your program has a bug and erroneously jumped to a non-code
==2414== location. If you are running Memcheck and you just saw a
==2414== warning about a bad jump, it's probably your program's fault.
==2414== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2414== i.e. it's Valgrind's fault. If you think this is the case or
==2414== you are not sure, please let us know and we'll try to fix it.
==2414== Either way, Valgrind will now raise a SIGILL signal which will
==2414== probably kill your program.
==2414== Thread 5:
==2414== Syscall param write(buf) points to uninitialised byte(s)
==2414== at 0x5153D12: write (syscall-template.S:84)
==2414== by 0x52B8A29: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Address 0x59d78f6 is 382 bytes inside a block of size 16,472 alloc'd
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5217FCB: ??? (in /usr/lib/arm-linux-gnueabihf/libssl.so.1.1)
==2414== Uninitialised value was created by a heap allocation
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x52CE4FB: BUF_MEM_grow_clean (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414==
==2414== HEAP SUMMARY:
==2414== in use at exit: 400 bytes in 2 blocks
==2414== total heap usage: 57,828 allocs, 57,826 frees, 4,335,151 bytes allocated
==2414==
==2414== Thread 1:
==2414== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414== LEAK SUMMARY:
==2414== definitely lost: 400 bytes in 2 blocks
==2414== indirectly lost: 0 bytes in 0 blocks
==2414== possibly lost: 0 bytes in 0 blocks
==2414== still reachable: 0 bytes in 0 blocks
==2414== suppressed: 0 bytes in 0 blocks
==2414==
==2414== For counts of detected and suppressed errors, rerun with: -v
==2414== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)
Since I've dealt with similar problems when using gdb I gave export OPENSSL_armcap=0 and then I got the following:
==2435== Memcheck, a memory error detector
==2435== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2435== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2435== Command: ./c++_app
==2435== Parent PID: 1556
==2435==
==2435==
==2435== HEAP SUMMARY:
==2435== in use at exit: 400 bytes in 2 blocks
==2435== total heap usage: 158,181 allocs, 158,179 frees, 11,872,290 bytes allocated
==2435==
==2435== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2435== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2435== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2435==
==2435== LEAK SUMMARY:
==2435== definitely lost: 400 bytes in 2 blocks
==2435== indirectly lost: 0 bytes in 0 blocks
==2435== possibly lost: 0 bytes in 0 blocks
==2435== still reachable: 0 bytes in 0 blocks
==2435== suppressed: 0 bytes in 0 blocks
==2435==
==2435== For counts of detected and suppressed errors, rerun with: -v
==2435== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
However no additional info was retrieved even though I've compiled the code with -ggdb3.
The info that I get from openssl version -a is:
OpenSSL 1.1.0j 20 Nov 2018
built on: reproducible build, date unspecified
platform: debian-armhf
options: bn(64,32) rc4(char) des(long) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/engines-1.1\""
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/arm-linux-gnueabihf/engines-1.1"
I've found several issues regarding memory leaks of the openssl but not one with so limited info.
Does anyone know if this memory leak is caused by libcrypto or false alarm of valgrind and is there any way to get additional info?
I have already seen this a few times. So far it was always a fault in my code. Because you shared no code, I can only give the latest issue in my case which caused this.
I was allocating a MAC code with the new OpenSSL 3 API with:
EVP_MAC *_mac = EVP_MAC_fetch(NULL, "cmac", NULL);
I forgot to deallocate this with:
EVP_MAC_free(_mac);

Extra allocs valgrind

Here is my valgrind output
$ valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes new
==14028== Memcheck, a memory error detector
==14028== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14028== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==14028== Command: new
==14028==
allocated
deleted
==14028==
==14028== HEAP SUMMARY:
==14028== in use at exit: 72,704 bytes in 1 blocks
==14028== total heap usage: 2 allocs, 1 frees, 72,754 bytes allocated
==14028==
==14028== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==14028== at 0x4C29C23: malloc (vg_replace_malloc.c:299)
==14028== by 0x4EBF18F: pool (eh_alloc.cc:117)
==14028== by 0x4EBF18F: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==14028== by 0x4EBF18F: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==14028== by 0x400FB02: _dl_init (in /usr/lib64/ld-2.17.so)
==14028== by 0x4001069: ??? (in /usr/lib64/ld-2.17.so)
==14028==
==14028== LEAK SUMMARY:
==14028== definitely lost: 0 bytes in 0 blocks
==14028== indirectly lost: 0 bytes in 0 blocks
==14028== possibly lost: 0 bytes in 0 blocks
==14028== still reachable: 72,704 bytes in 1 blocks
==14028== suppressed: 0 bytes in 0 blocks
==14028==
==14028== For counts of detected and suppressed errors, rerun with: -v
==14028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
As you can see the extra alloc seems to be from some source I can't identify, valgrind lists it as ???. Is this just some weird allocation behind the scenes? Should I worry about it?
This allocation/'still reachable' memory report is normal, and has been reported on valgrind bugzilla (and fixed) : see a.o. bugs https://bugs.kde.org/show_bug.cgi?id=345307 and https://bugs.kde.org/show_bug.cgi?id=348978.
You might need to upgrade to a newer valgrind and/or newer ld/glibc/... to have all that fixed.
If you cannot upgrade yet, in the meantime, you can use a suppression file.
Run valgrind + your program with the valgrind option --gen-suppressions=yes (or =all) to provide the needed suppression entry.

c++ char memory leakage with valgrind analysis

I have around 350 lines code where I am parsing xml file and creating another 2 sheets out of it using C++.
After adding the last 2 or 3 functions I started having memory error,
Signal: SIGSEGV (Segmentation fault)
Removing them didn't solve the error so definitely I edited something else. I searched online and found about valgrind which showed me errors that I can't translate.
As per the valgrind manual, I have to check from below to up so as per the last one,
==7276== 4,064 bytes in 1 blocks are definitely lost in loss record 52 of 54
==7276== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7276== by 0x456BDD: ??? (in /usr/bin/g++-5)
==7276== by 0x4EC260D: _obstack_begin (obstack.c:176)
==7276== by 0x456FCE: ??? (in /usr/bin/g++-5)
==7276== by 0x43BA49: ??? (in /usr/bin/g++-5)
==7276== by 0x43BAC0: ??? (in /usr/bin/g++-5)
==7276== by 0x4E5A82F: (below main) (libc-start.c:291)
For line 291 is the append line in the below code,
if (vlan_ether)
sprintf(cConfStr, "**.Switch%ld.eth[%d].queue.VlanClassifier = true\n", srcindex + 1, portno);
else if (!vlan_ether)
sprintf(cConfStr, "**.Switch%ld.eth[%d].queue.etherType = false\n", srcindex + 1, portno);
else
cout << "Switch" << srcindex + 1 << "port# " << portno << " Classifier is not specified." << endl;
confStr.append(string(cConfStr));
Removing the above lines didn't do any change, while line 176 is a comment so am hesitating that valgrind is not showing the lines of error.
So I am not sure what to show you in my question from the code. Still I am definite that it should be related to string and char usage In which I used them several times.
char cNedStr[600];
char cConfStr[600];
sprintf(cConfStr, "%d ", intervalvector[q]);
confStr.append(string(cConfStr));
The Valgrind result as per below,
amr#amr-PC:~$ valgrind --leak-check=yes g++ main.cpp pugixml.cpp headers.h -Wall -std=c++11
EDIT:
amr#amr-PC:~/ClionProjects/converter$ valgrind ./a.out
==7624== Memcheck, a memory error detector
==7624== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7624== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7624== Command: ./a.out
==7624== Invalid free() / delete / delete[] / realloc()
==7624== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7624== by 0x5714FF7: __run_exit_handlers (exit.c:82)
==7624== by 0x5715044: exit (exit.c:104)
==7624== by 0x56FB836: (below main) (libc-start.c:325)
==7624== Address 0x35663a37323a6536 is not stack'd, malloc'd or (recently) free'd
==7624==
==7624==
==7624== HEAP SUMMARY:
==7624== in use at exit: 72,704 bytes in 1 blocks
==7624== total heap usage: 525 allocs, 525 frees, 214,887 bytes allocated
==7624==
==7624== LEAK SUMMARY:
==7624== definitely lost: 0 bytes in 0 blocks
==7624== indirectly lost: 0 bytes in 0 blocks
==7624== possibly lost: 0 bytes in 0 blocks
==7624== still reachable: 72,704 bytes in 1 blocks
==7624== suppressed: 0 bytes in 0 blocks
==7624== Rerun with --leak-check=full to see details of leaked memory
==7624==
==7624== For counts of detected and suppressed errors, rerun with: -v
==7624== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
First compile, without the header file, (default output is a.out):
g++ main.cpp pugixml.cpp -Wall -std=c++11
Then check using valgrind:
valgrind --leak-check=yes ./a.out
Other comments:
You could consider adding the following flags to g++:
-Wextra (more warnings)
-pedantic (turns off extensions and generates more warnings)
-g (debug symbols)
-O3 (maximum optimization, not recommended for debugging!)

How do I prevent valgrind from showing 1 less "free" than "alloc"?

valgrind prints the following diagnostic from an empty program:
$cat main.cpp
int main(){}
$g++ -std=c++1z -o main main.cpp
$valgrind --leak-check=full --show-leak-kinds=all ./main
==26823== Memcheck, a memory error detector
==26823== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26823== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==26823== Command: ./main
==26823==
==26823==
==26823== HEAP SUMMARY:
==26823== in use at exit: 72,704 bytes in 1 blocks
==26823== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==26823==
==26823== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==26823== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26823== by 0x4E9D62F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22)
==26823== by 0x4010109: call_init.part.0 (dl-init.c:78)
==26823== by 0x40101F2: call_init (dl-init.c:36)
==26823== by 0x40101F2: _dl_init (dl-init.c:126)
==26823== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==26823==
==26823== LEAK SUMMARY:
==26823== definitely lost: 0 bytes in 0 blocks
==26823== indirectly lost: 0 bytes in 0 blocks
==26823== possibly lost: 0 bytes in 0 blocks
==26823== still reachable: 72,704 bytes in 1 blocks
==26823== suppressed: 0 bytes in 0 blocks
==26823==
==26823== For counts of detected and suppressed errors, rerun with: -v
==26823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Notice how it states:
"total heap usage: 1 allocs, 0 frees".
It is consistently off by 1 for programs where I also allocate and manage memory properly. This seems to be an issue with the lib standard itself? How can I fix this? I can't seem to find a compiler flag to prevent this.
I have the same issue using the clang++ frontend.

Valgrind C++ memory leak in empty file

I have a problem with "extra" memory leaks in valgrind. For example, I created a test program, called temp.cpp:
int main() { return 0; }
In the terminal, I run:
>> g++ -o temp.out temp.cpp
>> valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./temp.out
This results in several memory leaks. How could this be?
==4438== LEAK SUMMARY:
==4438== definitely lost: 4,120 bytes in 2 blocks
==4438== indirectly lost: 2,288 bytes in 6 blocks
==4438== possibly lost: 8,336 bytes in 99 blocks
==4438== still reachable: 6,440 bytes in 13 blocks
==4438== suppressed: 5,020 bytes in 73 blocks
I have tried running other .cpp files and I get the exact same leak summary. About a month ago when I tried, nothing was wrong. I might have upgraded Xcode or something, if that could be the issue (?). These are my settings for g++:
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
It seems valgrind have issues on MacOSX. While these issues are not fixed, a possible temporary solution would be the use of a suppression file. For further details, please check this other answer
I tried to reproduce this but I couldn't on my machine. It seems that there is no leak on the newest valgrind. Try brew upgrade valgrind
C02QH2D7G8WM:simple userone$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./temp.out
==1917== Memcheck, a memory error detector
==1917== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1917== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1917== Command: ./temp.out
==1917==
==1917==
==1917== HEAP SUMMARY:
==1917== in use at exit: 22,177 bytes in 189 blocks
==1917== total heap usage: 255 allocs, 66 frees, 27,953 bytes allocated
==1917==
==1917== 2,064 bytes in 1 blocks are possibly lost in loss record 57 of 62
==1917== at 0x10000817C: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==1917== by 0x1005E0EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D4182: protocols() (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D4093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D1C13: gc_init (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D924E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005E6132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D483C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D4300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D42E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D42E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917== by 0x1005D42E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917==
==1917== LEAK SUMMARY:
==1917== definitely lost: 0 bytes in 0 blocks
==1917== indirectly lost: 0 bytes in 0 blocks
==1917== possibly lost: 2,064 bytes in 1 blocks
==1917== still reachable: 0 bytes in 0 blocks
==1917== suppressed: 20,113 bytes in 188 blocks
==1917==
==1917== For counts of detected and suppressed errors, rerun with: -v
==1917== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 17)