mpiexec segmentation fault address not mapped - shared-libraries

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).
--------------------------------------------------------------------------

Related

Segmentation fault - invalid memory reference (Conditional jump or move depends on uninitialised value(s))

Here is the code I am trying to execute:
SUBROUTINE GRAD(tasklist_GRAD,ww,pas,cpt ,nb_element,cpt1,dt,dx,p_element,u_prime,u_prime_moins,u_prime_plus,&
&taux,grad_x_u,grad_t_u,grad_x_f,grad_t_f,ax_plus,ax_moins,ux_plus,ux_moins,sm,flux,tab0,tab)
INTEGER ::i,j,k,ff,pas
INTEGER,intent(inout)::cpt,cpt1,nb_element,ww
real*8 :: dt,dx
integer ,allocatable, dimension(:),intent(inout) ::p_element
REAL*8 ,allocatable, dimension(:),intent(inout) :: u_prime,u_prime_moins, u_prime_plus,taux,grad_x_u,&
&grad_t_u,grad_t_f,grad_x_f,flux,sm
real*8,allocatable,dimension(:),intent(inout) :: ax_plus,ax_moins,ux_moins,ux_plus
REAL*8 ,allocatable, dimension(:,:),intent(inout) ::tab0,tab
integer::num_thread,nthreads
integer, external :: OMP_GET_THREAD_NUM, OMP_GET_NUM_THREADS
type(tcb),dimension(20)::tasklist_GRAD,tasks_ready_master
integer,allocatable,dimension(:)::threads_list
integer,dimension(30)::threads_list_all
integer,dimension(3)::threads_list_part1
integer::threads_list_part2
integer,dimension(16)::threads_list_part3
type(tcb)::self
!-----------Calcul des gradients de x
Choisircese: select case (ww)
case(0) ! Old CESE
tasklist_GRAD(1)%f_ptr => u_prime_1 !1
tasklist_GRAD(2)%f_ptr => u_prime_droite_1 !2
tasklist_GRAD(3)%f_ptr => u_prime_gauche_1 !3
!$OMP PARALLEL PRIVATE(num_thread,nthreads) &
!$OMP SHARED(tasklist_GRAD,threads_list,threads_list_all,tasks_ready_master) &
!$OMP SHARED(threads_list_part1,threads_list_part2,threads_list_part3)
num_thread=OMP_GET_THREAD_NUM()
nthreads=OMP_GET_NUM_THREADS()
!Thread Application Master
!$OMP SINGLE
if (num_thread==1) then
do ff=1,3
if (associated(tasklist_GRAD(ff)%f_ptr) .eqv. .true. ) then
tasks_ready_master(ff) = tasklist_GRAD(ff)
end if
end do
do ff=1,3
if (associated(tasks_ready_master(ff)%f_ptr) .eqv. .true.) then
tasks_ready_master(ff)%state=STATE_READY
end if
end do
end if
!$OMP END SINGLE
!Thread Master
!$OMP SINGLE
if (num_thread==0) then
allocate(threads_list(nthreads-2))
do ff=1,nthreads-2
threads_list(ff)=ff+1
end do
do ff=1,3,nthreads-2
if (tasks_ready_master(ff)%state==STATE_READY) then
threads_list_all(ff:ff+nthreads-3)=threads_list(:)
end if
end do
threads_list_part1=threads_list_all(1:3)
end if
!$OMP END SINGLE
!Threads workers
do ff=1,3
if (num_thread==threads_list_part1(ff)) then
!$OMP TASK
call tasks_ready_master(ff)%f_ptr(self,ww,pas,cpt ,nb_element,cpt1,dt,dx,p_element,u_prime,u_prime_moins,&
&u_prime_plus,taux,grad_x_u,grad_t_u,grad_x_f,grad_t_f,ax_plus,ax_moins,ux_plus,ux_moins,sm,flux,tab0,tab)
!$OMP END TASK
end if
end do
!$OMP END PARALLEL
if(pas.eq.2)then
u_prime(2) = tab0(2,2)+dt/2.0d0*grad_x_u(2)!d_t_u(2)
u_prime(cpt-1) = tab0(cpt-1,2)+dt/2.0d0*grad_t_u(cpt-1)
u_prime(1) = tab0(1,2)+dt/2.0d0*grad_t_u(1)
u_prime(cpt) = tab0(cpt,2)+dt/2.0d0*grad_t_u(cpt)
u_prime_plus(1)= (u_prime(2)-tab(1,2))/(dx/2.0d0)
u_prime_moins(1)=-(u_prime(1)-tab(1,2))/(dx/2.0d0)
u_prime_plus(cpt)= (u_prime(cpt)-tab(cpt,2))/(dx/2.0d0)
u_prime_moins(cpt)= -(u_prime(cpt-1)-tab(cpt,2))/(dx/2.0d0)
end if
end select choisircese
END SUBROUTINE GRAD
The code is quite long so I only posted the case 0 (a sufficient part to understand the whole subroutine).
In order to compile, I do:
gfortran -fopenmp -O3 -g HECESE_openmp.f90
In order to execute, I do (I have fixed the number of threads previously):
./a.out
The error I get is:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7f0eae2d6700 in ???
#0 0x7f0eae2d6700 in ???
#0 0x7f0eae2d6700 in ???
#1 0x7f0eae2d58a5 in ???
#1 0x7f0eae2d58a5 in ???
#2 0x7f0eadf7520f in ???
#3 0x0 in ???
Erreur de segmentation (core dumped)
I decided so to use valgrind and I did:
valgrind --track-origins=yes ./a.out
and the errors I get are:
==10923== Thread 6:
==10923== Conditional jump or move depends on uninitialised value(s)
==10923== at 0x1153DE: __procedures_MOD_grad._omp_fn.4 (HECESE_openmp.f90:702)
==10923== by 0x4C81A85: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4F13608: start_thread (pthread_create.c:477)
==10923== by 0x4DCD292: clone (clone.S:95)
==10923== Uninitialised value was created by a stack allocation
==10923== at 0x10B22A: __procedures_MOD_grad (HECESE_openmp.f90:482)
==10923==
==10923== Thread 1:
==10923== Conditional jump or move depends on uninitialised value(s)
==10923== at 0x1153DE: __procedures_MOD_grad._omp_fn.4 (HECESE_openmp.f90:702)
==10923== by 0x4C78E75: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x10BF35: __procedures_MOD_grad (HECESE_openmp.f90:659)
==10923== by 0x1123CA: MAIN__ (HECESE_openmp.f90:1065)
==10923== by 0x113E45: main (HECESE_openmp.f90:723)
==10923== Uninitialised value was created by a stack allocation
==10923== at 0x10B22A: __procedures_MOD_grad (HECESE_openmp.f90:482)
==10923==
==10923== Thread 8:
==10923== Jump to the invalid address stated on the next line
==10923== at 0x0: ???
==10923== by 0x4C7BD7A: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4C846A7: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x1153A4: __procedures_MOD_grad._omp_fn.4 (HECESE_openmp.f90:674)
==10923== by 0x4C81A85: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4F13608: start_thread (pthread_create.c:477)
==10923== by 0x4DCD292: clone (clone.S:95)
==10923== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10923==
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
==10923== Thread 5:
==10923== Jump to the invalid address stated on the next line
==10923== at 0x0: ???
==10923== by 0x4C7BD7A: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4C846A7: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4C81A91: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4F13608: start_thread (pthread_create.c:477)
==10923== by 0x4DCD292: clone (clone.S:95)
==10923== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10923==
==10923== Thread 1:
==10923== Jump to the invalid address stated on the next line
==10923== at 0x0: ???
==10923== by 0x4C7BD7A: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4C846A7: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x4C8304C: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10923== by 0x10BF35: __procedures_MOD_grad (HECESE_openmp.f90:659)
==10923== by 0x1123CA: MAIN__ (HECESE_openmp.f90:1065)
==10923== by 0x113E45: main (HECESE_openmp.f90:723)
==10923== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10923==
#0 0x487e700 in ???
#1 0x487d8a5 in ???
#2 0x4cf120f in ???
#3 0x0 in ???
==10923==
==10923== Process terminating with default action of signal 11 (SIGSEGV)
==10923== at 0x4CF1169: raise (raise.c:46)
==10923== by 0x4CF120F: ??? (in /usr/lib/x86_64-linux-gnu/libc-2.31.so)
==10923==
==10923== HEAP SUMMARY:
==10923== in use at exit: 263,919 bytes in 122 blocks
==10923== total heap usage: 195 allocs, 73 frees, 330,511 bytes allocated
==10923==
==10923== LEAK SUMMARY:
==10923== definitely lost: 0 bytes in 0 blocks
==10923== indirectly lost: 0 bytes in 0 blocks
==10923== possibly lost: 3,344 bytes in 11 blocks
==10923== still reachable: 260,575 bytes in 111 blocks
==10923== suppressed: 0 bytes in 0 blocks
==10923== Rerun with --leak-check=full to see details of leaked memory
==10923==
==10923== For lists of detected and suppressed errors, rerun with: -s
==10923== ERROR SUMMARY: 165 errors from 5 contexts (suppressed: 0 from 0)
Erreur de segmentation (core dumped)
Can you help me please to find out where all these errors come from ? It was okay until I added the $!OMP SINGLE and retired the $!OMP BARRIER.

Consider
!$OMP SINGLE
if (num_thread==0) then
...
threads_list_part1=threads_list_all(1:3)
end if
!$OMP END SINGLE
!Threads workers
do ff=1,3
if (num_thread==threads_list_part1(ff)) then
The first thread that reaches this code will go into the single block. All other threads will then skip over it and wait at the implicit barrier at the end until the thread that entered the block finishes its work. If, and only if, the thread that enters the block is thread number 0 will the array threads_list_part1 get initialised. If any other thread enters the block it will not be initialised. You have no guarantee which thread enters the block so what you are seeing is a thread with number not zero being the first to reach the single block. Probable solution: just get rid of the if (num_thread==0) then and similarly for the other single block previous to it.
That said having seen what you are doing an even more OpenMP way of doing it might be to use parallel sections, about the first time I have ever seen that this might be a sensible thing to do.

Getting memory leaks in Glib/GDBus code?

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

Valgrind Memory Leak in strdup

I am doing a small Project. I am checking about memory leaks using the tool Valgrind. When I use this tool, I got the bellow information.
> 584 bytes in 74 blocks are definitely lost in loss record 103 of 104
> ==4628== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==4628== by 0x41CF8D0: strdup (strdup.c:43)
> ==4628== by 0x8060B95: main (in mycall)
>
> LEAK SUMMARY:
> ==4628== definitely lost: 584 bytes in 74 blocks
> ==4628== indirectly lost: 0 bytes in 0 blocks
> ==4628== possibly lost: 0 bytes in 0 blocks
> ==4628== still reachable: 21,414 bytes in 383 blocks
> ==4628== suppressed: 0 bytes in 0 blocks
> ==4628==
> ==4628== For counts of detected and suppressed errors, rerun with: -v
> ==4628== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
These are the codings I have used the function strdup. I have used in LEX code.
{string} {
yylval.string = strdup(yytext + 1);
yylval.string[yyleng - 2] = 0;
return PPSTRING;
}
{numvar} { yylval.string = strdup(yytext);return(PPNUMVAR); }
{sysnumvar} { yylval.string = (char *) strdup(yytext);return(PPSYSNUMVAR); }
I don't know in which point the memory has been leaked.

strdup function allocate necessary memory to store the sourcing string implicitly, you need to free the returned string (i.e., yylval.string in your code) manually.

Valgrind has reported "memory leak" when I compiled my program with "-pg" enabled?

I've get a memory leak reported by Valgrind with -pg enabled when compiling the following simple code.
#include <iostream>
#include <boost/filesystem.hpp>
#define BOOST_FILESYSTEM_VERSION 3
using boost::filesystem::path;
using namespace std;
int main() {
path ptDir;
ptDir = "/home/foo/bar";
if (true == is_directory((const path &)ptDir)){
cout << "ptDir: " << ptDir << endl;
}
}
The full compile option was as follows.
g++ -pg -g test.cpp -lboost_system -lboost_filesystem
The command of running valgrind is:
valgrind --gen-suppressions=all --track-origins=yes --error-limit=no --leak-check=full --show-reachable=yes -v --trace-children=yes --track-fds=yes --log-file=vg.log ./a.out
Then valgrind gave me a memory leak error.
==9598== HEAP SUMMARY:
==9598== in use at exit: 4,228 bytes in 1 blocks
==9598== total heap usage: 136 allocs, 135 frees, 17,984 bytes allocated
==9598==
==9598== Searching for pointers to 1 not-freed blocks
==9598== Checked 130,088 bytes
==9598==
==9598== 4,228 bytes in 1 blocks are still reachable in loss record 1 of 1
==9598== at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==9598== by 0x4260F44: monstartup (gmon.c:134)
==9598== by 0xBED6B636: ???
==9598== by 0x4E45504E: ???
==9598==
{
<insert_a_suppression_name_here>
Memcheck:Leak
fun:calloc
fun:monstartup
obj:*
obj:*
}
==9598== LEAK SUMMARY:
==9598== definitely lost: 0 bytes in 0 blocks
==9598== indirectly lost: 0 bytes in 0 blocks
==9598== possibly lost: 0 bytes in 0 blocks
==9598== still reachable: 4,228 bytes in 1 blocks
==9598== suppressed: 0 bytes in 0 blocks
==9598==
==9598== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==9598== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Is this correct? I'm using Ubuntu 12.04/ Kernel 3.2.0-32-generic

Valgrind FAQ:
"still reachable" means your program is probably ok -- it didn't free some
memory it could have. This is quite common and often reasonable. Don't use
--show-reachable=yes if you don't want to see these reports.

The fact that the allocatio comes from:
by 0x4260F44: monstartup (gmon.c:134)
indicates that it's a side effect of -pg - which is nothing you can do anything about. Don't mix -pg and valgrind is my suggestion.

alsa - mem leak?

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.

Resources