Thanks for the feedback, I think that if your intention is to hide the "free (NULL)" calls it should be perfectly fine, but in the general case maybe this is something that needs to be locked at, to see why the application is doing this. It is currently interpreted as a "double free" as the program thinks that the same address (0) is freed again without any intermediate allocation done at this address. >From the program output I see that even after your modification there are many more "free" calls than "malloc" calls, which hints to potential issues there. Please feel free to propose any modification or enhancements via github, as for example this issue with free(null) which is interpreted as a double free issue. Petros
On Sun, Nov 18, 2018 at 7:18 PM Robert <[email protected]> wrote: > I would also add: > > "arg0 != 0" > > condition into "free" func declaration in D script. It is causing a lot of > false double free stack warnings. > > E.g. boost libs like to call "free" with a zero arg a lot :) > > > Report with your original code: > > Call statistics > Found 2383 malloc calls > Found 153 calloc calls > Found 0 realloc calls > Found 15499 free calls > > Double free issues > Found 13066 double free stacks in total > Found 118 unique double free stacks > > > Report with free "arg0 != 0": > > Call statistics > Found 1232 malloc calls > Found 79 calloc calls > Found 0 realloc calls > Found 2990 free calls > > Double free issues > Found 1532 double free stacks in total > Found 51 unique double free stacks > > There are still many FPs which I'm now investigating. > > > On 11/15/18 9:17 AM, Robert Ayrapetyan wrote: > > Unfortunatelly I haven’t found one. Even reducing stack frame depth to 5 > didn’t helped. I think it can be optimized in dtrace code by eg not > resolving names in real time and post process later instead.. This may > really help alot > > On Mon, Nov 12, 2018 at 11:32 PM Petros Pissias <[email protected]> > wrote: > >> Hi Robert, >> Is there an alternative way to trace call stacks? >> Using a large buffer (i.e. 1 GB) might also help not to slow down the >> application too much. >> >> On Mon, Nov 12, 2018 at 4:25 PM Robert <[email protected]> >> wrote: >> >>> Unfortunately, ustack(50) you're using slows down execution order of >>> magnitude times. >>> >>> I was in a situation when whole mem leak situation didn't reproduced >>> because of that. >>> >>> >>> On 11/12/18 7:18 AM, Petros Pissias wrote: >>> >>> Hi everyone, >>> >>> I wanted to share a little tool I have created for supporting memory >>> leak investigations with dtrace. It has helped me in a couple of difficult >>> cases and I would like to share it with you. >>> >>> https://github.com/ppissias/DTLeakAnalyzer >>> >>> It follows from the excellent article from Brendan Gregg ( >>> http://www.brendangregg.com/Solaris/memoryflamegraphs.html ) and >>> implements some of the techniques with some of my own heuristics for >>> further pointing our suspect memory leaks. >>> >>> I wanted to share it in case is is useful for someone else, >>> >>> Petros >>> *dtrace-discuss* | Archives >>> <https://www.listbox.com/member/archive/184261/=now> | Modify >>> <https://www.listbox.com/member/?> Your Subscription >>> <https://www.listbox.com> >>> >>> ------------------------------------------- dtrace-discuss Archives: https://www.listbox.com/member/archive/184261/=now Modify Your Subscription: https://www.listbox.com/member/?member_id=25769126 Powered by Listbox: https://www.listbox.com
