[lvm-devel] LVM2 lib/metadata/lv_manip.c lib/metadata/meta ...

[Jonathan Brassow]

On Apr 7, 2011, at 3:35 PM, Zdenek Kabelac wrote:

> Dne 7.4.2011 17:20, Jonathan Brassow napsal(a):
>> 
>> On Apr 7, 2011, at 7:09 AM, Zdenek Kabelac wrote:
>> 
>>>> +
>>>> +	dm_pool_free(lv->vg->cmd->mem, img_name);
>>> 
>>> 
>>> Aren't you experiencing random crashes with this  dm_pool_free() ?
>>> It removes also all objects allocated past this img_name.
>>> (Also I think there is already an internal function for building such names)
>> 
>> No crashes so far... I haven't run into that while running through the test suite or my by-hand tests.  Why would I expect that kind of behavior?
> 
> See the comment for dm_pool_free() in libdevmapper.h
> As you are allocating LV after img_name - by this pool you are effectively
> removing all memory allocated in VG pool after.

Thank-you for mentioning this!  Gah.  Alright, I'll fix that.  I'm surprised too now that I haven't seen problems.

> 
>> 
>> Also, do you know what the name of the internal function would be to replace my 'alloc, fill with template name, create empty lv's, free' sequence?
>> 
> 
> Ok - it looks like for _mimage_ - there is not yet one - so as there are
> already 3 other placed - it might be forth to create one for this purpose.
> 
> (Also note - in other case we are already using simplier ,"%s_mimage_%%d",
> (see the _split_mirror_images() in mirror.c)

Well, there are a couple different things going on in _split_mirror_images.  In one case, the space is created at the time the variable is declared ('format' is allocated on the stack).  In the other, that string ("_mimage_%d") is passed to a function.

In this case, I could easily create the space for img_name on the stack, i think.

 brassow