Bug 1003278

Summary: [abrt] lvm2-2.02.98-12.fc19: _free_chunk: Process /usr/sbin/lvmetad was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Dean Hunter <deanhunter>
Component: lvm2Assignee: LVM and device-mapper development team <lvm-team>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: agk, bmarzins, bmr, dwysocha, heinzm, jonathan, lvm-team, msnitzer, prajnoha, prockai, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:51acf5d197033006a21003cf7461f157075e6bae
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-22 08:50:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Dean Hunter 2013-09-01 14:54:00 UTC 
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
Comment 1 Dean Hunter 2013-09-01 14:54:06 UTC 
Created attachment 792598 [details]
File: backtrace
Comment 2 Dean Hunter 2013-09-01 14:54:10 UTC 
Created attachment 792599 [details]
File: cgroup
Comment 3 Dean Hunter 2013-09-01 14:54:14 UTC 
Created attachment 792600 [details]
File: core_backtrace
Comment 4 Dean Hunter 2013-09-01 14:54:18 UTC 
Created attachment 792601 [details]
File: dso_list
Comment 5 Dean Hunter 2013-09-01 14:54:22 UTC 
Created attachment 792602 [details]
File: environ
Comment 6 Dean Hunter 2013-09-01 14:54:26 UTC 
Created attachment 792603 [details]
File: exploitable
Comment 7 Dean Hunter 2013-09-01 14:54:30 UTC 
Created attachment 792604 [details]
File: limits
Comment 8 Dean Hunter 2013-09-01 14:54:35 UTC 
Created attachment 792605 [details]
File: maps
Comment 9 Dean Hunter 2013-09-01 14:54:38 UTC 
Created attachment 792606 [details]
File: open_fds
Comment 10 Dean Hunter 2013-09-01 14:54:43 UTC 
Created attachment 792607 [details]
File: proc_pid_status
Comment 11 Dean Hunter 2013-09-01 14:54:47 UTC 
Created attachment 792608 [details]
File: var_log_messages
Comment 12 Zdenek Kabelac 2013-09-02 14:38:53 UTC 
I believe this one has been fixed by:

https://www.redhat.com/archives/lvm-devel/2013-June/msg00416.html
Comment 13 Peter Rajnoha 2013-09-03 07:22:00 UTC 
(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.
Comment 14 Zdenek Kabelac 2013-09-03 08:13:16 UTC 
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
Comment 15 Zdenek Kabelac 2013-10-22 08:50:55 UTC 

*** This bug has been marked as a duplicate of bug 1000894 ***