[llvm-dev] How to ask MustAlias queries from DSA results

杨至轩(Zhixuan Yang) via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 19 01:18:26 PST 2016


Dear John,


> When you say "must be allocated," you mean it must have been allocated via a call to a heap allocator (e.g., malloc(), calloc(), etc), correct?


Yes, I mean heap allocators. In fact, I'm implementing the idea of the ICSE 2015 paper Safe Memory-Leak Fixing for C Programs.



> Also, are you performing intra-procedural or inter-procedural data-flow analysis?


Currently, I only wrote a intraprocedural version. It is expected to be extended to inter-procedural quickly.


> If you're going to transform the program, I would recommend that you use SAFECode's new BBAC feature to track the base address.  BBAC has a run-time library which can take a pointer to a memory object and calculate, in constant time, the first address of the memory object into which the pointer is pointing.  You could use this to find the base address of the memory object so that you can pass it to the free() function.  As BBAC is a referent object approach, it doesn't suffer from the compatibility problems that fat pointer approaches suffer.


For my task, it performs whole-program analysis. And I think "external code" problem can be ignored if we don't try to fix malloc() leaks in third-party library. 


Compared with fat-pointers, I don't need to pass additional information (in my case, back-up of the address returned by a malloc()) around the program. I only need to pass it from the malloc() call site to the place where I want to free() it. In the worst case, I can simply add a new global variable.


In my task, I want to fix leaks in the C source code rather than relying on runtime libraries. Now, I think it's not necessary to use BBAC in my task. Maybe I will change my idea if I find too few bugs can be fixed without relying on any runtime libraries. 


Thanks a lot.


Regards, Zhixuan Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161219/0675799e/attachment.html>


More information about the llvm-dev mailing list