Hi, On Fri, Feb 27, 2015 at 11:43 PM, Gary Mohr <gary.m...@bull.com> wrote: > Hi Stephane, > > > > I was just wondering if you had a chance to look at the libpfm4 patch file I > sent a few weeks ago to fix some problems where heap space was getting > stranded. The description of the problems and valgrind output report can be > found in the emails below. I have also attached another copy of the patch > file to this email. > I have applied your patch.
As for the fstr problem, the fact that it needs to be freed by the caller (if requested by the caller) is already documented in the man page. I remphasized it more in that man page to make it clear the user must free it. Thanks for tracking done the memory leaks. > > > BTW: I have seen email addresses for you on both gmail.com and > googlemail.com, which do you prefer ?? > They all go to the same address! > > > Thanks > > Gary > > > > From: Gary Mohr > Sent: Monday, February 09, 2015 1:20 PM > To: Gary Mohr; eran...@gmail.com > Cc: perfmon2-devel > Subject: RE: Stranded memory valgrind report for libpfm4. > > > > 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) ------------------------------------------------------------------------------ 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
