BUG: memleak part 3 (CFFI only) #819
Conversation
I'll see if I can figure out what's going on here, that seems like it could be a problem |
* this should be reviewed after darshan-hpcgh-816, and fixes the residual memory leak there so that we get a flat memory profile with repeated calls to `log_get_generic_record()` * note that `RUNTIME` heatmap doesn't seem to like the extra `free()`, it causes some testing issues, so I've excluded that here--hopefully that module just doesn't have the same problem..
* drop some spurious `free()` usages for cases where `darshan_log_get_record()` hasn't `malloc`'d anything
tylerjereddy
force-pushed
the
treddy_issue_811_part3_cffi_only
branch
from
af603fb to
3f0647d
Compare
|
Ok, I think I addressed the comments so far. I also rebased to vastly simplify the displayed diff. |
* `free()` memory that is allocated by darshan-util library for heatmap records * use `np.copy()` to make a copy of heatmap read/write arrays to avoid them from being freed out from under heatmap records
I think I fixed the memory leak and the test errors via b21d644, which looked like they were ultimately caused by incorrect data being stored in heatmap records when we add in the necessary @tylerjereddy if it looks good to you, I think we can go ahead and merge. I'm not sure if we had a good reproducer for the heatmap module-specific memory leak, but might be good to confirm this is working as expected in terms of leaking if we do. |
|
@shanedsnyder Probably not HEATMAP reproducer yet, but maybe we can include that separately as part of #817. I'd probably just lift the reproducers from gh-811, and supplement for any modules not covered there, if needed. I guess that means putting stuff in the Once this is merged (it looks sensible to me as well) maybe we should ping in gh-811 for user confirmation of the fix if they are comfortable recompiling from |
this should be reviewed after BUG: memleak fix CFFI only pt1 #816, and fixes
the residual memory leak there so that we get
a flat memory profile with repeated calls
to
log_get_generic_record(); after rebasing, this PRshould simplify to a few CFFI backend changes to free
buf[0]in a few places and make explicit copies for NumPywhere it is pointing to the dropped memory buffer
note that
RUNTIMEheatmap doesn't seem to likethe extra
free(), it causes some testing issues,so I've excluded that here--hopefully that module
just doesn't have the same problem..
Gradual mem spike -> flat profile: