Hide Forgot
Description of problem: virsh vol-create-as --name $domain --pool Guests --capacity $capacity Version-Release number of selected component: lvm2-2.02.98-12.fc19 Additional info: reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: /usr/sbin/lvmetad crash_function: _free_chunk executable: /usr/sbin/lvmetad kernel: 3.10.9-200.fc19.x86_64 runlevel: N 5 uid: 0 Truncated backtrace: Thread no. 1 (8 frames) #2 _free_chunk at mm/pool-fast.c:313 #3 dm_pool_destroy at mm/pool-fast.c:75 #4 dm_config_destroy at libdm-config.c:126 #5 update_metadata at lvmetad-core.c:757 #6 vg_update at lvmetad-core.c:933 #7 handler at lvmetad-core.c:1071 #8 client_thread at daemon-server.c:392 #10 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Created attachment 792598 [details] File: backtrace
Created attachment 792599 [details] File: cgroup
Created attachment 792600 [details] File: core_backtrace
Created attachment 792601 [details] File: dso_list
Created attachment 792602 [details] File: environ
Created attachment 792603 [details] File: exploitable
Created attachment 792604 [details] File: limits
Created attachment 792605 [details] File: maps
Created attachment 792606 [details] File: open_fds
Created attachment 792607 [details] File: proc_pid_status
Created attachment 792608 [details] File: var_log_messages
I believe this one has been fixed by: https://www.redhat.com/archives/lvm-devel/2013-June/msg00416.html
(In reply to Zdenek Kabelac from comment #12) > I believe this one has been fixed by: > > https://www.redhat.com/archives/lvm-devel/2013-June/msg00416.html This one's already in lvm2-2.02.98-12.fc19.
Hmm - so we have few more suspects which may have influence on lvmetad memory handling: error paths: 54e062265074766becc06d2fdb0020ade56cf95d f787b575b52fcbfa8327d083eae4f2baf296b1cf ff5c1c576c9f0162e9d82becfe30b100fc601c88 lvmetad func: 382fc878d7be5252d7ad93f2740ee25bd500d53e 06243be91b12a7bb249d2b18cf5eeb0492ccfa4f Of course it would be very helpful to have more info about how the dm table was looking. Also at least adding 'export MALLOC_CHECK_=1' before execution of lvmetad would have helped (modifying systemd service ?) Is this bug repeatable or occurs only seldomly ? Starting lvmetad -f (with -debuginfo package installed) in the valgrind environment would be probably the best. Seems to be closely related to Bug #1000894
*** This bug has been marked as a duplicate of bug 1000894 ***