[Lldb-commits] [lldb] r333700 - [IRMemoryMap] Test interleaved Mallocs and Frees

[Vedant Kumar via lldb-commits]

Patch up for review: https://reviews.llvm.org/D47646 <https://reviews.llvm.org/D47646>

thanks,
vedant

> On Jun 1, 2018, at 11:31 AM, Vedant Kumar <vsk at apple.com> wrote:
> 
> 
> 
>> On Jun 1, 2018, at 1:39 AM, Pavel Labath <labath at google.com> wrote:
>> 
>> On Thu, 31 May 2018 at 23:13, Vedant Kumar via lldb-commits
>> <lldb-commits at lists.llvm.org> wrote:
>>> 
>>> Author: vedantk
>>> Date: Thu May 31 15:09:01 2018
>>> New Revision: 333700
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=333700&view=rev
>>> Log:
>>> [IRMemoryMap] Test interleaved Mallocs and Frees
>>> 
>>> This adds a new command to the ir-memory-map tester:
>>> 
>>> free <allocation-index>
>>> 
>>> The argument to free is an index which identifies which live allocation
>>> to free. Index 0 identifies the first live allocation in the address
>>> space, index 1 identifies the second, etc. where the allocations are
>>> sorted in increasing order.
>>> 
>>> For illustrative purposes, assume malloc returns monotonically
>>> increasing addresses. Here are some examples of how free would work:
>>> 
>>> Example 1
>>> ---------
>>> 
>>> malloc 16 1
>>> malloc 32 1
>>> free 1      //< Free the 32-byte allocation.
>>> free 0      //< Next, free the 16-byte allocation.
>> 
>> I think it would be better if the mallocs and frees were connected
>> symbolically instead of by an index that changes after every free. In
>> the long test case you add here it's pretty much impossible to figure
>> out which allocation a particular free refers to.
>> 
>> Maybe we could
>> attach an optional "label" to each malloc statement and then have
>> "free" reference those? e.g. something like:
>> LARGEALLOC: malloc 4096 16
>> malloc 10, 1 # I won't free this, no label necessary
>> free LARGEALLOC # frees first allocation
>> 
>> Adding parsing code for the extended syntax shouldn't be much work,
>> but I believe it will help a lot with the readability of these test
>> cases.
>> 
>> WDYT?
> 
> I think this would be a good forward-looking change to make. Maybe it'll help test other parts of the API: we have no testing for WriteMemory, or for what happens on a double-free.
> 
> As an aside, for this particular test case, I'm not sure there's a reason to figure out which allocation a free refers to. It might actually be sufficient to have the free command pick a random allocation to release (i.e, no arguments).
> 
> vedant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180601/d199e777/attachment.html>