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

[Vedant Kumar via lldb-commits]

> 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