opencv imshow and imwrite give realloc error - c++

I have an OGRE::Image img object whose PixelFormat is PF_BYTE_RGBA, I convert it to cv::Mat with following code
cv::Mat modelImage;
modelImage.create(img.getHeight(), img.getWidth(), CV_8UC3);
int copyChannels[6] = {0,2,1,1,2,0};
cv::Mat ogre2mat(img.getHeight(), img.getWidth(), CV_8UC4, img.getData());
mixChannels(&ogre2mat, 1, &modelImage, 1, copyChannels, 3);
Now, this prints the values perfectly :
cout << modelImage.row(0) << endl;
But one of the following code give realloc() error
imwrite("img.png",modelImage);
imshow("img",modelImage);
Also, I get following as output from valgrind. Looks like some error on Qt
==28986== Memcheck, a memory error detector
==28986== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28986== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==28986== Command: ./run diver.urdf
==28986==
==28986== Invalid free() / delete / delete[] / realloc()
==28986== at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28986== by 0xFA26E3D: QListData::realloc(int) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1)
==28986== by 0xFA26EF9: QListData::append(int) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1)
==28986== by 0xFB13D8B: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1)
==28986== by 0xFB0FE28: qRegisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1)
==28986== by 0xF9B2EB2: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1)
==28986== by 0x4010139: call_init.part.0 (dl-init.c:78)
==28986== by 0x4010222: _dl_init (dl-init.c:36)
==28986== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==28986== by 0x1: ???
==28986== by 0xFFEFFFE02: ???
==28986== by 0xFFEFFFE08: ???
==28986== Address 0xbf7e840 is 0 bytes inside data symbol "_ZN9QListData11shared_nullE"
==28986==
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
==28986==
==28986== HEAP SUMMARY:
==28986== in use at exit: 73,525 bytes in 636 blocks
==28986== total heap usage: 1,557 allocs, 921 frees, 117,760 bytes allocated
==28986==
==28986== LEAK SUMMARY:
==28986== definitely lost: 0 bytes in 0 blocks
==28986== indirectly lost: 0 bytes in 0 blocks
==28986== possibly lost: 14,005 bytes in 300 blocks
==28986== still reachable: 59,520 bytes in 336 blocks
==28986== suppressed: 0 bytes in 0 blocks
==28986== Rerun with --leak-check=full to see details of leaked memory
==28986==
==28986== For counts of detected and suppressed errors, rerun with: -v
==28986== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Aborted

I followed following steps and it worked.
1) I uninstalled the opencv libary.
2) Downloaded the version 2.4.10
3) Installed the dependencies as shown in
http://robotics.jacobs-university.de/TMP/kaustubh/vision/install_opencv_latest.txt
3) Then followed both the approaches described in http://www.aichengxu.com/view/52596 (It is in Chinese, google translate will help). I updated Gstreamer with
sudo apt-get install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
But it did not work.
5) Second approach worked. So I set
WITH_GSTREAMER_0_10=OFF
and
WITH_QT=OFF
in
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_TBB=ON -D BUILD_NEW_PYTHON_SUPPORT=ON -D WITH_V4L=ON -D INSTALL_C_EXAMPLES=ON -D INSTALL_PYTHON_EXAMPLES=ON -D BUILD_EXAMPLES=ON -D WITH_QT=OFF -D WITH_OPENGL=ON WITH_GSTREAMER_0_10 = OFF ..
Then,
make && make install
Basically, the error was something to do with Qt.

Related

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 shows memory leak with empty main without including headers

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.

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)