2011/9/28 Alexander Lyakas <alex.bolshoy@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
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
