Hi Stephane, Today I found some other paths through the libpfm4 code that could lead to stranding memory allocated by pfmlib_build_event_pattrs. The attached patch file has the fixes and comments mentioned in the previous email plus code to also correct these other paths through the code (so they do not strand memory allocated by the above function).
Gary From: Gary Mohr [mailto:gary.m...@bull.com] Sent: Friday, February 06, 2015 5:04 PM To: eran...@gmail.com Cc: perfmon2-devel Subject: [perfmon2] Stranded memory valgrind report for libpfm4. Hi Stephane, I ran valgrind on a simple papi program and the results showed memory loss due to code in both papi and libpfm4. The data presented at the bottom of this email shows the 3 libpfm4 related stacks shown by valgrind. I have looked at these and think I have figured out why each of them strands memory. I think I have a fix for the first and last stack shown in the valgrind output. But I am not sure what to do about the middle one. When the attached patch is applied the first and last sets of lost memory blocks disappear. The middle stack strands memory because the papi library called pfm_get_os_event_encoding() and the last argument (which points at an pfm_perf_encode_arg_t structure) contains a non-null fstr value. This causes libpfm4 to malloc some space in pfmlib_build_fstr(). It looks to me like the pointer to this malloced space is returned to the papi library and he did not free it. The attached patch inserts a comment into the code where the pointer to the malloc space is being returned to the caller but does not actually do anything to fix the problem. Do we want libpfm4 allocating heap space that the user who calls it has to free ?? Thanks Gary ==11932== ==11932== HEAP SUMMARY: ==11932== in use at exit: 67,357,218 bytes in 128 blocks ==11932== total heap usage: 1,069 allocs, 941 frees, 68,141,569 bytes allocated ==11932== ==11932== Searching for pointers to 128 not-freed blocks ==11932== Checked 67,710,040 bytes ==11932== ==11932== 1,152 bytes in 2 blocks are definitely lost in loss record 7 of 12 ==11932== at 0x52009EE: malloc (vg_replace_malloc.c:270) ==11932== by 0x475D49: pfmlib_build_event_pattrs (pfmlib_common.c:1037) ==11932== by 0x476119: pfmlib_parse_equiv_event (pfmlib_common.c:1124) ==11932== by 0x4763ED: pfmlib_parse_event (pfmlib_common.c:1221) ==11932== by 0x4755ED: pfm_find_event (pfmlib_common.c:814) ==11932== by 0x445E46: allocate_native_event (pe_libpfm4_events.c:230) ==11932== by 0x447AD4: _pe_libpfm4_ntv_name_to_code (pe_libpfm4_events.c:512) ==11932== by 0x4431D8: _pe_ntv_name_to_code (perf_event.c:1732) ==11932== by 0x437E19: _papi_load_preset_table (papi_preset.c:496) ==11932== by 0x44BC12: _pe_libpfm4_init (pe_libpfm4_events.c:1146) ==11932== by 0x443126: _pe_init_component (perf_event.c:1694) ==11932== by 0x426785: _papi_hwi_init_global (papi_internal.c:1907) ==11932== ==11932== 2,649 bytes in 40 blocks are definitely lost in loss record 8 of 12 ==11932== at 0x52009EE: malloc (vg_replace_malloc.c:270) ==11932== by 0x474F75: pfmlib_build_fstr (pfmlib_common.c:589) ==11932== by 0x47A6C0: pfmlib_perf_event_encode (pfmlib_perf_event.c:319) ==11932== by 0x4766CE: pfm_get_os_event_encoding (pfmlib_common.c:1319) ==11932== by 0x445A98: allocate_native_event (pe_libpfm4_events.c:173) ==11932== by 0x447AD4: _pe_libpfm4_ntv_name_to_code (pe_libpfm4_events.c:512) ==11932== by 0x4431D8: _pe_ntv_name_to_code (perf_event.c:1732) ==11932== by 0x437E19: _papi_load_preset_table (papi_preset.c:496) ==11932== by 0x44BC12: _pe_libpfm4_init (pe_libpfm4_events.c:1146) ==11932== by 0x443126: _pe_init_component (perf_event.c:1694) ==11932== by 0x426785: _papi_hwi_init_global (papi_internal.c:1907) ==11932== by 0x407644: PAPI_library_init (papi.c:615) ==11932== ==11932== 38,016 bytes in 38 blocks are definitely lost in loss record 10 of 12 ==11932== at 0x52009EE: malloc (vg_replace_malloc.c:270) ==11932== by 0x475D49: pfmlib_build_event_pattrs (pfmlib_common.c:1037) ==11932== by 0x476417: pfmlib_parse_event (pfmlib_common.c:1227) ==11932== by 0x4755ED: pfm_find_event (pfmlib_common.c:814) ==11932== by 0x445E46: allocate_native_event (pe_libpfm4_events.c:230) ==11932== by 0x447AD4: _pe_libpfm4_ntv_name_to_code (pe_libpfm4_events.c:512) ==11932== by 0x4431D8: _pe_ntv_name_to_code (perf_event.c:1732) ==11932== by 0x437E19: _papi_load_preset_table (papi_preset.c:496) ==11932== by 0x44BC12: _pe_libpfm4_init (pe_libpfm4_events.c:1146) ==11932== by 0x443126: _pe_init_component (perf_event.c:1694) ==11932== by 0x426785: _papi_hwi_init_global (papi_internal.c:1907) ==11932== by 0x407644: PAPI_library_init (papi.c:615) ==11932== ==11932== LEAK SUMMARY: ==11932== definitely lost: 41,817 bytes in 80 blocks ==11932== indirectly lost: 0 bytes in 0 blocks ==11932== possibly lost: 0 bytes in 0 blocks ==11932== still reachable: 67,315,401 bytes in 48 blocks ==11932== suppressed: 0 bytes in 0 blocks ==11932== Reachable blocks (those to which a pointer was found) are not shown. ==11932== To see them, rerun with: --leak-check=full --show-reachable=yes ==11932== ==11932== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6) --11932-- --11932-- used_suppression: 4 U1004-ARM-_dl_relocate_object --11932-- used_suppression: 2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a ==11932== ==11932== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6)
Libpfm4LostMemory.patch
Description: Libpfm4LostMemory.patch
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
