I am trying check memory leaks in my code, and valgrind is showing many error. As I have never used valgrind before, I need help.
To start with, I am concentrating to the default gtk call's.
as coded, memory is leaked from mkbib.c's line number 140. But line number 140 is just
gtk_init(&argc, &argv);
I have used
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
--leak-check=full --leak-resolution=high --num-callers=20
--log-file=vgdump --suppressions=gtk.suppression ./mkbib
which, along with gtk.suppression is taken from valgrind-gnome Live
==28420== 16 bytes in 1 blocks are definitely lost in loss record 2,413 of 10,955
==28420== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420== by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x311C611176: ??? (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420== by 0x311C60C19D: atk_bridge_adaptor_init (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420== by 0x311D50257B: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x403F65: main (mkbib.c:140)
==28420==
==28420== 16 bytes in 1 blocks are definitely lost in loss record 2,414 of 10,955
==28420== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420== by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x311C611176: ??? (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420== by 0x311C60C1DD: atk_bridge_adaptor_init (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420== by 0x311D50257B: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x403F65: main (mkbib.c:140)
==28420==
==28420== 24 bytes in 1 blocks are possibly lost in loss record 3,468 of 10,955
==28420== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420== by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x310CA63F65: g_memdup (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x310D22D274: ??? (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420== by 0x310D22DFCC: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420== by 0x311D5022C7: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311A6154C8: atk_add_focus_tracker (in /usr/lib64/libatk-1.0.so.0.20609.1)
==28420== by 0x311D502567: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x403F65: main (mkbib.c:140)
==28420==
==28420== 24 bytes in 1 blocks are possibly lost in loss record 3,469 of 10,955
==28420== at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==28420== by 0x310CA4D6E6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x310D22DF00: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420== by 0x310D22DD4E: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420== by 0x310D21E7BF: g_param_spec_flags (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420== by 0x311D4C27BB: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x310D22E0B5: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420== by 0x311D5022C7: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311A6154C8: atk_add_focus_tracker (in /usr/lib64/libatk-1.0.so.0.20609.1)
==28420== by 0x311D502567: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420== by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420== by 0x403F65: main (mkbib.c:140)
I have found some discussion that valgrind is not good to detect memory leaks in gtk. is this one of such cases, that I should ignore? or I am missing something?
my system involved is:
gtk3-devel-3.6.4-1.fc18.x86_64
valgrind-3.8.1-9.fc18.x86_64
gcc(GCC) 4.7.2 20121109
For the time being you should concentrate on the leaks detected explicitely in your part of the code. Valgrind often finds leaks on external components you cannot modify, even commercial libraries. You can consult the documentation for ignore files, they suppres output of errors coming from certain libraries:
http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
Try modifying suppression file to be more generic, excerpted example:
...
obj:/usr/lib64/libgtk* (issue seems to apply to any gtk version, including gtk-2)
fun:g_option_context_parse
fun:gtk_parse_args (or could just use "...")
fun:gtk_init* (also applies to gtk_init_check)
Related
I was trying to use some open-source cfd code, after I compiled it.
But when I typed command 'mpiexec ./data -tis 0 -tie 9700 -ts 100', It returned error message
[songyi719-thinkpad-x1-extreme-2nd:13862] *** Process received signal ***
[songyi719-thinkpad-x1-extreme-2nd:13862] Signal: Segmentation fault (11)
[songyi719-thinkpad-x1-extreme-2nd:13862] Signal code: Address not mapped (1)
[songyi719-thinkpad-x1-extreme-2nd:13862] Failing at address: 0x440000e8
[songyi719-thinkpad-x1-extreme-2nd:13862] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f1206c313c0]
[songyi719-thinkpad-x1-extreme-2nd:13862] [ 1] /usr/local/lib/libmpi.so.40(MPI_Comm_rank+0x3b)[0x7f1206e1a71b]
[songyi719-thinkpad-x1-extreme-2nd:13862] [ 2] ./data(+0x3a432)[0x55a320d75432]
[songyi719-thinkpad-x1-extreme-2nd:13862] [ 3] ./data(+0x98d9)[0x55a320d448d9]
[songyi719-thinkpad-x1-extreme-2nd:13862] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f1206a510b3]
[songyi719-thinkpad-x1-extreme-2nd:13862] [ 5] ./data(+0xa33e)[0x55a320d4533e]
[songyi719-thinkpad-x1-extreme-2nd:13862] *** End of error message ***
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 13862 RUNNING AT songyi719-thinkpad-x1-extreme-2nd
= EXIT CODE: 139
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions
What could this mean? I am totally noob to MPI.
Also, I tried to find where memory leaked using valgrind.
==12707== Memcheck, a memory error detector
==12707== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12707== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==12707== Command: ./data -tis 0 -tie 9700 -ts 100
==12707==
==12708== Memcheck, a memory error detector
==12708== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12708== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==12708== Command: /usr/local/bin/orted --hnp --set-sid --report-uri 19 --singleton-died-pipe 20 -mca state_novm_select 1 -mca ess hnp -mca pmix ^s1,s2,cray,isolated
==12708==
==12707== Conditional jump or move depends on uninitialised value(s)
==12707== at 0x6782BEA: PMIx_Get_nb (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x67836BD: PMIx_Get (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x677A9F5: PMIx_Init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x6742C5A: pmix3x_client_init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x5F17E4D: rte_init.part.0 (in /usr/local/lib/openmpi/mca_ess_singleton.so)
==12707== by 0x595EBCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5239782: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== Invalid read of size 1
==12707== at 0x51CA71B: PMPI_Comm_rank (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x142431: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== Address 0x440000e8 is not stack'd, malloc'd or (recently) free'd
==12707==
[songyi719-thinkpad-x1-extreme-2nd:12707] *** Process received signal ***
[songyi719-thinkpad-x1-extreme-2nd:12707] Signal: Segmentation fault (11)
[songyi719-thinkpad-x1-extreme-2nd:12707] Signal code: Address not mapped (1)
[songyi719-thinkpad-x1-extreme-2nd:12707] Failing at address: 0x440000e8
[songyi719-thinkpad-x1-extreme-2nd:12707] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x54093c0]
[songyi719-thinkpad-x1-extreme-2nd:12707] [ 1] /usr/local/lib/libmpi.so.40(MPI_Comm_rank+0x3b)[0x51ca71b]
[songyi719-thinkpad-x1-extreme-2nd:12707] [ 2] ./data(+0x3a432)[0x142432]
[songyi719-thinkpad-x1-extreme-2nd:12707] [ 3] ./data(+0x98d9)[0x1118d9]
[songyi719-thinkpad-x1-extreme-2nd:12707] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x543e0b3]
[songyi719-thinkpad-x1-extreme-2nd:12707] [ 5] ./data(+0xa33e)[0x11233e]
[songyi719-thinkpad-x1-extreme-2nd:12707] *** End of error message ***
==12707==
==12707== Process terminating with default action of signal 11 (SIGSEGV)
==12707== at 0x5409229: raise (raise.c:46)
==12707== by 0x5A066AB: show_stackframe (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x54093BF: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==12707== by 0x51CA71A: PMPI_Comm_rank (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x142431: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== HEAP SUMMARY:
==12707== in use at exit: 2,952,075 bytes in 10,345 blocks
==12707== total heap usage: 22,923 allocs, 12,578 frees, 4,968,761 bytes allocated
==12707==
==12707== 1 bytes in 1 blocks are definitely lost in loss record 2 of 8,075
==12707== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12707== by 0x54B950E: strdup (strdup.c:42)
==12707== by 0x7DD6536: ???
==12707== by 0x7DB6373: ???
==12707== by 0x59F33CB: mca_base_framework_components_register (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x59F3765: mca_base_framework_register (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x59F37C3: mca_base_framework_open (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x5239B94: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== 37 bytes in 1 blocks are definitely lost in loss record 5,335 of 8,075
==12707== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12707== by 0x54A5DC7: __vasprintf_internal (vasprintf.c:71)
==12707== by 0x5549742: __asprintf_chk (asprintf_chk.c:34)
==12707== by 0x5A20A6D: opal_hwloc_base_get_locality_string (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x5928302: orte_ess_base_proc_binding (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5F18EF2: rte_init.part.0 (in /usr/local/lib/openmpi/mca_ess_singleton.so)
==12707== by 0x595EBCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5239782: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== 79 (64 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 6,379 of 8,075
==12707== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12707== by 0x791414E: mca_mpool_hugepage_open (in /usr/local/lib/openmpi/mca_mpool_hugepage.so)
==12707== by 0x59E912C: mca_base_framework_components_open (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x5A57C05: mca_mpool_base_open (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x59F3838: mca_base_framework_open (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x5239B35: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 6,520 of 8,075
==12707== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12707== by 0x5A24ADF: opal_hwloc201_hwloc_bitmap_alloc (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x592879B: orte_ess_base_proc_binding (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5F18EF2: rte_init.part.0 (in /usr/local/lib/openmpi/mca_ess_singleton.so)
==12707== by 0x595EBCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5239782: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== 304 bytes in 1 blocks are possibly lost in loss record 7,820 of 8,075
==12707== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12707== by 0x40149CA: allocate_dtv (dl-tls.c:286)
==12707== by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==12707== by 0x53FE322: allocate_stack (allocatestack.c:622)
==12707== by 0x53FE322: pthread_create##GLIBC_2.2.5 (pthread_create.c:660)
==12707== by 0x59CD869: opal_thread_start (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x59CD1FE: opal_progress_thread_init (in /usr/local/lib/libopen-pal.so.40.30.0)
==12707== by 0x5F17DB4: rte_init.part.0 (in /usr/local/lib/openmpi/mca_ess_singleton.so)
==12707== by 0x595EBCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5239782: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== 304 bytes in 1 blocks are possibly lost in loss record 7,821 of 8,075
==12707== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12707== by 0x40149CA: allocate_dtv (dl-tls.c:286)
==12707== by 0x40149CA: _dl_allocate_tls (dl-tls.c:532)
==12707== by 0x53FE322: allocate_stack (allocatestack.c:622)
==12707== by 0x53FE322: pthread_create##GLIBC_2.2.5 (pthread_create.c:660)
==12707== by 0x6752AA9: pmix_thread_start (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x67BA808: pmix_progress_thread_start (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x67B9A27: pmix_rte_init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x6779B40: PMIx_Init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x6742C5A: pmix3x_client_init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x5F17E4D: rte_init.part.0 (in /usr/local/lib/openmpi/mca_ess_singleton.so)
==12707== by 0x595EBCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5239782: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707==
==12707== LEAK SUMMARY:
==12707== definitely lost: 126 bytes in 4 blocks
==12707== indirectly lost: 79 bytes in 2 blocks
==12707== possibly lost: 608 bytes in 2 blocks
==12707== still reachable: 2,951,262 bytes in 10,337 blocks
==12707== suppressed: 0 bytes in 0 blocks
==12707== Reachable blocks (those to which a pointer was found) are not shown.
==12707== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==12707==
==12707== Use --track-origins=yes to see where uninitialised values come from
==12707== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
==12707==
==12707== 1 errors in context 1 of 8:
==12707== Invalid read of size 1
==12707== at 0x51CA71B: PMPI_Comm_rank (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x142431: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== Address 0x440000e8 is not stack'd, malloc'd or (recently) free'd
==12707==
==12707==
==12707== 1 errors in context 2 of 8:
==12707== Conditional jump or move depends on uninitialised value(s)
==12707== at 0x6782BEA: PMIx_Get_nb (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x67836BD: PMIx_Get (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x677A9F5: PMIx_Init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x6742C5A: pmix3x_client_init (in /usr/local/lib/openmpi/mca_pmix_pmix3x.so)
==12707== by 0x5F17E4D: rte_init.part.0 (in /usr/local/lib/openmpi/mca_ess_singleton.so)
==12707== by 0x595EBCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12707== by 0x5239782: ompi_mpi_init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x51DBB62: PMPI_Init (in /usr/local/lib/libmpi.so.40.30.0)
==12707== by 0x1423C0: PetscInitialize (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707== by 0x1118D8: main (in /home/songyi719/Desktop/Research/SAFL-CFD-Lab-VFS-Wind-041aae8/Instructional_Cases/Test_01_3D_Sloshing/data)
==12707==
==12707== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
==12708==
==12708== HEAP SUMMARY:
==12708== in use at exit: 23,320 bytes in 288 blocks
==12708== total heap usage: 20,484 allocs, 20,196 frees, 4,292,387 bytes allocated
==12708==
==12708== 5 bytes in 1 blocks are definitely lost in loss record 8 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x49E550E: strdup (strdup.c:42)
==12708== by 0x527EEEE: ???
==12708== by 0x522F128: ???
==12708== by 0x48A6CBC: pmix_server_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x51CA9E5: ???
==12708== by 0x48F0BCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489D60C: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 38 bytes in 1 blocks are definitely lost in loss record 28 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x49E550E: strdup (strdup.c:42)
==12708== by 0x51CAFC3: ???
==12708== by 0x48F0BCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489D60C: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 38 bytes in 1 blocks are definitely lost in loss record 29 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x49E550E: strdup (strdup.c:42)
==12708== by 0x51CB099: ???
==12708== by 0x48F0BCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489D60C: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 136 bytes in 1 blocks are definitely lost in loss record 56 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x48E2609: orte_rmaps_base_print_mapping (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x48A9556: orte_pmix_server_register_nspace (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489E644: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 152 bytes in 1 blocks are definitely lost in loss record 58 of 81
==12708== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x4BB87CC: opal_libevent2022_event_base_once (event.c:1707)
==12708== by 0x529FB62: ???
==12708== by 0x527E00E: ???
==12708== by 0x522FD45: ???
==12708== by 0x48A716F: pmix_server_finalize (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x51C9E33: ???
==12708== by 0x487E7D4: orte_finalize (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489DD96: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 668 (96 direct, 572 indirect) bytes in 2 blocks are definitely lost in loss record 70 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x528578F: ???
==12708== by 0x528BCA4: ???
==12708== by 0x5280F2D: ???
==12708== by 0x5282035: ???
==12708== by 0x52E1F31: ???
==12708== by 0x4BB72C2: event_process_active_single_queue (event.c:1370)
==12708== by 0x4BB72C2: event_process_active (event.c:1440)
==12708== by 0x4BB72C2: opal_libevent2022_event_base_loop (event.c:1644)
==12708== by 0x529F385: ???
==12708== by 0x4929608: start_thread (pthread_create.c:477)
==12708== by 0x4A65292: clone (clone.S:95)
==12708==
==12708== 1,212 (640 direct, 572 indirect) bytes in 1 blocks are definitely lost in loss record 75 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x527E5BF: ???
==12708== by 0x522F128: ???
==12708== by 0x48A6CBC: pmix_server_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x51CA9E5: ???
==12708== by 0x48F0BCB: orte_init (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489D60C: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 2,048 bytes in 1 blocks are definitely lost in loss record 77 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x4B72DA3: opal_dss_buffer_extend (in /usr/local/lib/libopen-pal.so.40.30.0)
==12708== by 0x4B74EF5: opal_dss_pack_int32 (in /usr/local/lib/libopen-pal.so.40.30.0)
==12708== by 0x4B74F79: opal_dss_pack (in /usr/local/lib/libopen-pal.so.40.30.0)
==12708== by 0x48AA143: orte_pmix_server_register_nspace (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489E644: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 2,048 bytes in 1 blocks are definitely lost in loss record 78 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x4B72DA3: opal_dss_buffer_extend (in /usr/local/lib/libopen-pal.so.40.30.0)
==12708== by 0x4B74EF5: opal_dss_pack_int32 (in /usr/local/lib/libopen-pal.so.40.30.0)
==12708== by 0x4B74F79: opal_dss_pack (in /usr/local/lib/libopen-pal.so.40.30.0)
==12708== by 0x48AA23F: orte_pmix_server_register_nspace (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x489E644: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== 5,614 (240 direct, 5,374 indirect) bytes in 1 blocks are definitely lost in loss record 81 of 81
==12708== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12708== by 0x489D4A8: orte_daemon (in /usr/local/lib/libopen-rte.so.40.30.0)
==12708== by 0x10916D: main (in /usr/local/bin/orted)
==12708==
==12708== LEAK SUMMARY:
==12708== definitely lost: 5,441 bytes in 11 blocks
==12708== indirectly lost: 6,518 bytes in 135 blocks
==12708== possibly lost: 0 bytes in 0 blocks
==12708== still reachable: 11,361 bytes in 142 blocks
==12708== suppressed: 0 bytes in 0 blocks
==12708== Reachable blocks (those to which a pointer was found) are not shown.
==12708== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==12708==
==12708== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 0 from 0)
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 12707 RUNNING AT songyi719-thinkpad-x1-extreme-2nd
= EXIT CODE: 139
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions
I also tried to open this 'data' shared library file, but unfortunately it was not composed of x-sharedlib, not C++. So I couldn't find the problem through code.
Update:
I've followed the comment and re-compiled petsc and my program.
It seems like it became even worse...
[songyi719-thinkpad-x1-extreme-2nd:400137] *** Process received signal ***
[songyi719-thinkpad-x1-extreme-2nd:400137] Signal: Segmentation fault (11)
[songyi719-thinkpad-x1-extreme-2nd:400137] Signal code: Address not mapped (1)
[songyi719-thinkpad-x1-extreme-2nd:400137] Failing at address: 0x440000e8
[songyi719-thinkpad-x1-extreme-2nd:400138] *** Process received signal ***
[songyi719-thinkpad-x1-extreme-2nd:400138] Signal: Segmentation fault (11)
[songyi719-thinkpad-x1-extreme-2nd:400138] Signal code: Address not mapped (1)
[songyi719-thinkpad-x1-extreme-2nd:400138] Failing at address: 0x440000e8
[songyi719-thinkpad-x1-extreme-2nd:400139] *** Process received signal ***
[songyi719-thinkpad-x1-extreme-2nd:400139] Signal: Segmentation fault (11)
[songyi719-thinkpad-x1-extreme-2nd:400139] Signal code: Address not mapped (1)
[songyi719-thinkpad-x1-extreme-2nd:400139] Failing at address: 0x440000e8
[songyi719-thinkpad-x1-extreme-2nd:400136] *** Process received signal ***
[songyi719-thinkpad-x1-extreme-2nd:400136] Signal: Segmentation fault (11)
[songyi719-thinkpad-x1-extreme-2nd:400136] Signal code: Address not mapped (1)
[songyi719-thinkpad-x1-extreme-2nd:400136] Failing at address: 0x440000e8
[songyi719-thinkpad-x1-extreme-2nd:400137] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fd8390913c0]
[songyi719-thinkpad-x1-extreme-2nd:400137] [ 1] [songyi719-thinkpad-x1-extreme-2nd:400138] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fdcdd9e43c0]
[songyi719-thinkpad-x1-extreme-2nd:400138] [ 1] /usr/local/lib/libmpi.so.40(MPI_Comm_rank+0x3b)[0x7fdcddbcd71b]
[songyi719-thinkpad-x1-extreme-2nd:400138] [ 2] ./data(+0x3a432)[0x561338ba4432]
[songyi719-thinkpad-x1-extreme-2nd:400139] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f52593b23c0]
[songyi719-thinkpad-x1-extreme-2nd:400139] [ 1] /usr/local/lib/libmpi.so.40(MPI_Comm_rank+0x3b)[0x7f525959b71b]
[songyi719-thinkpad-x1-extreme-2nd:400139] [ 2] ./data(+0x3a432)[0x5621d8ba1432]
[songyi719-thinkpad-x1-extreme-2nd:400139] [ 3] ./data(+0x98d9)[0x5621d8b708d9]
[songyi719-thinkpad-x1-extreme-2nd:400139] [songyi719-thinkpad-x1-extreme-2nd:400138] [ 3] ./data(+0x98d9)[0x561338b738d9]
[songyi719-thinkpad-x1-extreme-2nd:400138] [ 4] /usr/local/lib/libmpi.so.40(MPI_Comm_rank+0x3b)[0x7fd83927a71b]
[songyi719-thinkpad-x1-extreme-2nd:400137] [ 2] ./data(+0x3a432)[0x56089fc48432]
[songyi719-thinkpad-x1-extreme-2nd:400137] [ 3] ./data(+0x98d9)[0x56089fc178d9]
[songyi719-thinkpad-x1-extreme-2nd:400137] [ 4] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f52591d20b3]
[songyi719-thinkpad-x1-extreme-2nd:400139] [ 5] ./data(+0xa33e)[0x5621d8b7133e]
[songyi719-thinkpad-x1-extreme-2nd:400139] *** End of error message ***
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fd838eb10b3]
[songyi719-thinkpad-x1-extreme-2nd:400137] [ 5] ./data(+0xa33e)[0x56089fc1833e]
[songyi719-thinkpad-x1-extreme-2nd:400137] *** End of error message ***
[songyi719-thinkpad-x1-extreme-2nd:400136] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fd3fb5143c0]
[songyi719-thinkpad-x1-extreme-2nd:400136] [ 1] /usr/local/lib/libmpi.so.40(MPI_Comm_rank+0x3b)[0x7fd3fb6fd71b]
[songyi719-thinkpad-x1-extreme-2nd:400136] [ 2] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fdcdd8040b3]
[songyi719-thinkpad-x1-extreme-2nd:400138] [ 5] ./data(+0xa33e)[0x561338b7433e]
[songyi719-thinkpad-x1-extreme-2nd:400138] *** End of error message ***
./data(+0x3a432)[0x555663876432]
[songyi719-thinkpad-x1-extreme-2nd:400136] [ 3] ./data(+0x98d9)[0x5556638458d9]
[songyi719-thinkpad-x1-extreme-2nd:400136] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fd3fb3340b3]
[songyi719-thinkpad-x1-extreme-2nd:400136] [ 5] ./data(+0xa33e)[0x55566384633e]
[songyi719-thinkpad-x1-extreme-2nd:400136] *** End of error message ***
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec noticed that process rank 1 with PID 0 on node songyi719-thinkpad-x1-extreme-2nd exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
I'm using GDBus (via Glib) and I have code like:
method_call_message = g_dbus_message_new_method_call(owner,
OBJECT_PATH,
INTERFACE_NAME,
"get_snmpv2_mib");
GVariant *gv = g_variant_new("(sissi)", ip, port, mib, variable, instance);
g_dbus_message_set_body(method_call_message, gv);
I assume method_call_message is now a container for gv.
Before exiting I call:
g_object_unref(method_call_message);
I assume this will then schedule BOTH method_call_message and gv for GC?
When is GC done?
I appear to be leaking some 4 bytes at a time as I watch the top updates on VIRT memory.
I have commented out pieces of code till I localized it (the leak) to my GDBus calls.
Using some Valgrind magic:
libtool exec valgrind --tool=memcheck --leak-check=full --log-file=w <executable + args>
I was able to winnow out the memory management obfuscation and get to a call-stack that showed the problem. The Valgrind output indicated that all my memory losses were associated with calls to g_variant_get(...):
at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==20088== by 0x3F21E503B6: g_malloc (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E6860D: g_strdup (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E7FD01: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E7FA61: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E80348: g_variant_get_va (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E80585: g_variant_get (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x4C30555: server_gvariant (in /usr/lib64/libdrsnvc.so)
==20088== by 0x40257B: NVCtimerCB(void*) (main.cc:73)
==20088== by 0x3F21E48C3A: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E48519: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E4A5A7: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
Obviously the call to g_variant_get(...) begats a call to g_strdup(...) (if your format_string includes an 's' for string). So, in my case, the code is:
g_variant_get(response, "(isi)", &od.stat, &od.msg, &od.i);
gchar *tmp = od.msg;
od.msg = strncpy(msg, od.msg, strlen(od.msg)); /* copy string */
g_free(tmp); /* free g_strdup allocated space */
And a call to g_free(...) frees the allocated storage.
Now I get:
LEAK SUMMARY:
==6472== definitely lost: 0 bytes in 0 blocks
==6472== indirectly lost: 0 bytes in 0 blocks
==6472== possibly lost: 9,841 bytes in 148 blocks
==6472== still reachable: 106,376 bytes in 986 blocks
==6472== suppressed: 0 bytes in 0 blocks
When I extract and iterate over the cashflows in a fixed rate bond, Valgrind reports a memory leak. I am using the following code:
FixedRateBond fixedRateBond(
settlementDays,
faceAmount,
fixedBondSchedule,
std::vector<Rate>(1, couponRate),
ActualActual(ActualActual::Bond),
BusinessDayConvention ::Unadjusted,
redemption,
issueDate
);
vector<boost::shared_ptr<CashFlow>> cashFlows = fixedRateBond.cashflows();
for (size_t i=0; i != cashFlows.size(); ++i) {
cout << "Date: " << cashFlows[i]->date() << " Amount: " << cashFlows[i]->amount() <<endl;
}
Edit: Looks like it's an OSX issue as the same code doesn't raise any issues when run in Linux. For posterity, here is the report I was getting on OSX:
==62096== 148 (80 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 170 of 208
==62096== at 0x1001F8EA1: malloc (vg_replace_malloc.c:303)
==62096== by 0x102D3D4A2: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D3DDEB: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D3A443: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D6307A: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D8C35C: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D705A8: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D70607: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102D60AB1: snprintf_l (in /usr/lib/system/libsystem_c.dylib)
==62096== by 0x102ACD752: std::__1::num_put<char, std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > >::do_put(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, std::__1::ios_base&, char, double) const (in /usr/lib/libc++.1.dylib)
==62096== by 0x102AB3B33: std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(double) (in /usr/lib/libc++.1.dylib)
==62096== by 0x10000A2D1: main (main.cpp:31)
This seems to be related to OS X as the issue does not occur on Linux and as (the always helpful) Luigi states is not in QuantLib code itself.
I have a very simple CUDA component in my application. Valgrind reports a lot of leaks and still-reachables, all related to the cudaMalloc calls.
Are these leaks real? I call cudaFree for every cudaMalloc. Is this valgrind's inability to interpret GPU memory allocation? If these leaks are not real, can I suppress them and have valgrind only analyse the non-gpu part of the application?
extern "C"
unsigned int *gethash(int nodec, char *h_nodev, int len) {
unsigned int *h_out = (unsigned int *)malloc(sizeof(unsigned int) * nodec);
char *d_in;
unsigned int *d_out;
cudaMalloc((void**) &d_in, sizeof(char) * len * nodec);
cudaMalloc((void**) &d_out, sizeof(unsigned int) * nodec);
cudaMemcpy(d_in, h_nodev, sizeof(char) * len * nodec, cudaMemcpyHostToDevice);
int blocks = 1 + nodec / 512;
cube<<<blocks, 512>>>(d_out, d_in, nodec, len);
cudaMemcpy(h_out, d_out, sizeof(unsigned int) * nodec, cudaMemcpyDeviceToHost);
cudaFree(d_in);
cudaFree(d_out);
return h_out;
}
Last bit of the Valgrind output:
...
==5727== 5,468 (5,020 direct, 448 indirect) bytes in 1 blocks are definitely lost in loss record 506 of 523
==5727== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5727== by 0x4843910: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x48403E9: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x498B32D: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x494A6E4: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x4849534: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x48191DD: cuInit (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x406B4D6: ??? (in /usr/lib/i386-linux-gnu/libcudart.so.5.0.35)
==5727== by 0x406B61F: ??? (in /usr/lib/i386-linux-gnu/libcudart.so.5.0.35)
==5727== by 0x408695D: cudaMalloc (in /usr/lib/i386-linux-gnu/libcudart.so.5.0.35)
==5727== by 0x804A006: gethash (hashkernel.cu:36)
==5727== by 0x804905F: chkisomorphs (bdd.c:326)
==5727==
==5727== LEAK SUMMARY:
==5727== definitely lost: 10,240 bytes in 6 blocks
==5727== indirectly lost: 1,505 bytes in 54 blocks
==5727== possibly lost: 7,972 bytes in 104 blocks
==5727== still reachable: 626,997 bytes in 1,201 blocks
==5727== suppressed: 0 bytes in 0 blocks
It's a known issue that valgrind reports false-positives for a bunch of CUDA stuff. The best way to avoid seeing it would be to use valgrind suppressions, which you can read all about here:
http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
If you want to jumpstart into something a little closer to your specific issue, an interesting post is this one on the Nvidia dev forums. It has a link to a sample suppression rule file.
https://devtalk.nvidia.com/default/topic/404607/valgrind-3-4-suppressions-a-little-howto/
Try using cuda-memcheck --leak-check full. Cuda-memcheck is a set of tools that provides similar functionality to Valgrind for CUDA applications. It is installed as part of the CUDA toolkit. You can get more documentation about how to use cuda-memcheck here : http://docs.nvidia.com/cuda/cuda-memcheck/
Note that cuda-memcheck is not a direct replacement for valgrind and can't be used to detect host side memory leaks or buffer overflows.
To add to scarl3tt's answer, this may be overly general for some applications, but if you want to use valgrind while ignoring most of the cuda issues, use the option --suppressions=valgrind-cuda.supp where valgrind-cuda.supp is a file with the following rules:
{
alloc_libcuda
Memcheck:Leak
match-leak-kinds: reachable,possible
fun:*alloc
...
obj:*libcuda.so*
...
}
{
alloc_libcufft
Memcheck:Leak
match-leak-kinds: reachable,possible
fun:*alloc
...
obj:*libcufft.so*
...
}
{
alloc_libcudaart
Memcheck:Leak
match-leak-kinds: reachable,possible
fun:*alloc
...
obj:*libcudart.so*
...
}
I wouldn't trust valgrind or any other leak detector (like VLD) with CUDA. I'm sure they weren't designed with GPU allocations in mind. I don't know whether Nvidia's Nsight has the capability these days (I haven't done GPU programming for almost 6 months now), but that's the best thing I used for CUDA debugging, and to be quite honest, it was buggy as hell.
The code you've posted shouldn't create a leak.
Since I don't have 50 reputation, I cannot leave a comment on #Vyas 's answer.
I feel strange that cuda-memcheck cannot observe cuda memory leakage.
I just write a very simple code with a cuda memory leakage, but when using cuda-memcheck --leak-check full it give no leakage. It is:
#include <iostream>
#include <cuda_runtime.h>
using namespace std;
int main(){
float* cpu_data;
float* gpu_data;
int buf_size = 10 * sizeof(float);
cpu_data = (float*)malloc(buf_size);
for(int i=0; i<10; i++){
cpu_data[i] = 1.0f * i;
}
cudaError_t cudaStatus = cudaMalloc(&gpu_data, buf_size);
cudaMemcpy(gpu_data, cpu_data, buf_size, cudaMemcpyHostToDevice);
free(cpu_data);
//cudaFree(gpu_data);
return 0;
}
Note the commented line of code, which make this program a cuda memory leakage, I think. However, when execuing cuda-memcheck ./a.out it gives:
========= CUDA-MEMCHECK
========= ERROR SUMMARY: 0 errors
I've been chasing a memory leak (reported by 'valgrind --leak-check=yes') and it appears to be coming from ALSA. This code has been in the free world for some time so I'm guessing that it's something I'm doing wrong.
#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>
int main (int argc, char *argv[])
{
snd_ctl_t *handle;
int err = snd_ctl_open( &handle, "hw:1", 0 );
printf( "snd_ctl_open: %d\n", err );
err = snd_ctl_close(handle);
printf( "snd_ctl_close: %d\n", err );
}
The output looks like this:
[root#aeolus alsa]# valgrind --leak-check=yes ./test2
==16296== Memcheck, a memory error detector
==16296== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==16296== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==16296== Command: ./test2
==16296==
snd_ctl_open: 0
snd_ctl_close: 0
==16296==
==16296== HEAP SUMMARY:
==16296== in use at exit: 22,912 bytes in 1,222 blocks
==16296== total heap usage: 1,507 allocs, 285 frees, 26,236 bytes allocated
==16296==
==16296== 4 bytes in 2 blocks are possibly lost in loss record 1 of 62
==16296== at 0x4007100: malloc (vg_replace_malloc.c:270)
==16296== by 0x340F7F: strdup (in /lib/libc-2.5.so)
==16296== by 0x624C6B5: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CA5B: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CD81: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624F311: snd_config_update_r (in /lib/libasound.so.2.0.0)
==16296== by 0x624FAD7: snd_config_update (in /lib/libasound.so.2.0.0)
==16296== by 0x625DA22: snd_ctl_open (in /lib/libasound.so.2.0.0)
==16296== by 0x804852F: main (test2.cpp:9)
and continues for some pages to
==16296== 2,052 bytes in 57 blocks are possibly lost in loss record 62 of 62
==16296== at 0x4005EB4: calloc (vg_replace_malloc.c:593)
==16296== by 0x624A268: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624A38F: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CA33: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CCC9: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CD81: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624F311: snd_config_update_r (in /lib/libasound.so.2.0.0)
==16296== by 0x624FAD7: snd_config_update (in /lib/libasound.so.2.0.0)
==16296== by 0x625DA22: snd_ctl_open (in /lib/libasound.so.2.0.0)
==16296== by 0x804852F: main (test2.cpp:9)
==16296==
==16296== LEAK SUMMARY:
==16296== definitely lost: 0 bytes in 0 blocks
==16296== indirectly lost: 0 bytes in 0 blocks
==16296== possibly lost: 22,748 bytes in 1,216 blocks
==16296== still reachable: 164 bytes in 6 blocks
==16296== suppressed: 0 bytes in 0 blocks
==16296== Reachable blocks (those to which a pointer was found) are not shown.
==16296== To see them, rerun with: --leak-check=full --show-reachable=yes
==16296==
==16296== For counts of detected and suppressed errors, rerun with: -v
==16296== ERROR SUMMARY: 56 errors from 56 contexts (suppressed: 19 from 8)
This came about as I'm using ALSA in a project and started seeing this huge leak...or at least the report of said leak.
So the question is: is it me, ALSA or valgrind that's having issues here?
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=MEMORY-LEAK;hb=HEAD says:
Memory leaks - really?
----------------------
Note that some developers are thinking that the ALSA library has some memory
leaks. Sure, it can be truth, but before contacting us, please, be sure that
these leaks are not forced.
The biggest reported leak is that the global configuration is cached for
next usage. If you do not want this feature, simply, call
snd_config_update_free_global() after all snd_*_open*() calls. This function
will free the cache.
The biggest reported leak is that the global configuration is cached for next usage.
If you do not want this feature, simply call snd_config_update_free_global() after all snd_*_open*() calls.
This function will free the cache." <---- Valgrind still detects leaks.
This can be fixed if you call snd_config_update_free_global() after snd_pcm_close(handle);
Perhaps this will work (source):
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
## -2171,7 +2171,12 ## static int snd_pcm_open_conf(snd_pcm_t **pcmp, const char *name,
if (open_func) {
err = open_func(pcmp, name, pcm_root, pcm_conf, stream, mode);
if (err >= 0) {
- (*pcmp)->open_func = open_func;
+ if ((*pcmp)->open_func) {
+ /* only init plugin (like empty, asym) */
+ snd_dlobj_cache_put(open_func);
+ } else {
+ (*pcmp)->open_func = open_func;
+ }
err = 0;
} else {
snd_dlobj_cache_put(open_func);
I tried it myself, but to no avail. My core temp heats up ~10 °F, most likely due to similar memory leak. Here's some of what valgrind gave me, even after using the patch above:
==869== 16,272 bytes in 226 blocks are possibly lost in loss record 103 of 103
==869== at 0x4C28E48: calloc (vg_replace_malloc.c:566)
==869== by 0x5066E61: _snd_config_make (in /usr/lib64/libasound.so.2)
==869== by 0x5066F58: _snd_config_make_add (in /usr/lib64/libasound.so.2)
==869== by 0x50673B9: parse_value (in /usr/lib64/libasound.so.2)
==869== by 0x50675DE: parse_array_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067680: parse_array_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A8E: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
The number of bytes lost just keeps going up and up.