[linux-lvm] LVM2.2.02.88 - segfault when using lv_t pointers obtained from lvm_vg_list_lvs

[Zdenek Kabelac]

2011/9/28 Alexander Lyakas <alex.bolshoy at gmail.com>:
> Hi everybody,
> we started to work with this LVM version, and sometimes we hit an
> issue when using lv_t pointers obtained from lvm_vg_list_lvs() API.
> Here are a couple of examples:
>
> #0  0x00007f4487816d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007f4487816d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007f448781aa47 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x00007f448784fd7b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x00007f448785cd7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #4  0x00007f448785f31e in malloc () from /lib/x86_64-linux-gnu/libc.so.6
> #5  0x00007f448784e75f in open_memstream () from /lib/x86_64-linux-gnu/libc.so.6

Looks like you hit some internal glibc malloc  integrity selfcheck -
so some memory has been unexpectedly modified - I'd advise to use
valgrind tool to find proper place when the memory is overwritten.

>        if (lv_list != NULL) {
>                dm_list_iterate_items(lv_list_entry, lv_list) {
>                        const char * lv_name_from_list = lvm_lv_get_name(lv_list_entry->lv);
>                        if (strcmp(lv_name_from_list, lv_name) == 0) {
>                                lv_handle = lv_list_entry->lv;
>                                break;
>                        }
>                }
>        }
>
> This is the code that we obtain the lv_t pointers from. Looking at the
> new  lvm_lv_from_name() API, it does exactly the same (without giving
> away copies of the list, names etc).  We started using the new API
> anyways, and did not see any crashes with it (yet).
>
> Is there anything wrong in the way we obtain lv_t pointers? Could this
> be some other issue?


Depends on, what do you do with pointers - you can't use them once you
free vg handle.
But I think valgrind will be here better then 1000 words....

Zdenek