Bug 966566

Summary: [abrt] pulseaudio-3.0-7.el7: snd_pcm_area_copy: Process /usr/bin/pulseaudio was killed by signal 6 (SIGABRT)
Product: Red Hat Enterprise Linux 7 Reporter: Martin Bříza <mbriza>
Component: pulseaudioAssignee: Wim Taymans <wtaymans>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: jkysela, mbriza, wtaymans
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:5501400e87b511712f4ed0421231177f3122d739
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-04 16:19:19 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: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Martin Bříza 2013-05-23 13:38:09 UTC 
Description of problem:
Happened right after logging in.

Version-Release number of selected component:
pulseaudio-3.0-7.el7

Additional info:
reporter:       libreport-2.1.4
backtrace_rating: 4
cmdline:        /usr/bin/pulseaudio --start --log-target=syslog
crash_function: snd_pcm_area_copy
executable:     /usr/bin/pulseaudio
kernel:         3.9.0-0.55.el7.x86_64
runlevel:       N 5
uid:            1000

Truncated backtrace:
Thread no. 1 (6 frames)
 #4 snd_pcm_area_copy at /usr/lib64/libasound.so.2
 #5 snd_pcm_areas_copy at /usr/lib64/libasound.so.2
 #6 snd_pcm_softvol_write_areas at /usr/lib64/libasound.so.2
 #7 snd_pcm_plugin_mmap_commit at /usr/lib64/libasound.so.2
 #8 thread_func at /usr/lib64/pulse-3.0/modules/libalsa-util.so
 #9 internal_thread_func at /usr/lib64/pulseaudio/libpulsecommon-3.0.so
Comment 1 Martin Bříza 2013-05-23 13:38:16 UTC 
Created attachment 752212 [details]
File: backtrace
Comment 2 Martin Bříza 2013-05-23 13:38:19 UTC 
Created attachment 752213 [details]
File: cgroup
Comment 3 Martin Bříza 2013-05-23 13:38:22 UTC 
Created attachment 752214 [details]
File: core_backtrace
Comment 4 Martin Bříza 2013-05-23 13:38:25 UTC 
Created attachment 752215 [details]
File: dso_list
Comment 5 Martin Bříza 2013-05-23 13:38:28 UTC 
Created attachment 752216 [details]
File: environ
Comment 6 Martin Bříza 2013-05-23 13:38:30 UTC 
Created attachment 752217 [details]
File: limits
Comment 7 Martin Bříza 2013-05-23 13:38:39 UTC 
Created attachment 752218 [details]
File: maps
Comment 8 Martin Bříza 2013-05-23 13:38:42 UTC 
Created attachment 752219 [details]
File: open_fds
Comment 9 Martin Bříza 2013-05-23 13:38:45 UTC 
Created attachment 752220 [details]
File: proc_pid_status
Comment 10 Martin Bříza 2013-05-23 13:38:48 UTC 
Created attachment 752221 [details]
File: var_log_messages
Comment 12 Wim Taymans 2014-02-19 13:33:27 UTC 
This assertion looks like it's triggered because of overlapping areas when doing a memcpy. It does not look like the source memory and the slave memory should ever use the same memory regions unless some memory corruption is at play.

Can this be reproduced? Did it ever happen again?
Comment 13 Martin Bříza 2014-02-19 13:36:53 UTC 
I didn't really try when I reported the bug and now it doesn't happen at all.