RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 989552 - [abrt] pulseaudio-3.0-10.el7: raise: Process /usr/bin/pulseaudio was killed by signal 6 (SIGABRT)
Summary: [abrt] pulseaudio-3.0-10.el7: raise: Process /usr/bin/pulseaudio was killed b...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pulseaudio
Version: 7.0
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Wim Taymans
QA Contact: Desktop QE
URL:
Whiteboard: abrt_hash:a4b1402f096b11fa1e7a227cdac...
: 1017741 (view as bug list)
Depends On: 1067032
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-29 14:14 UTC by Vadim Rutkovsky
Modified: 2015-03-05 10:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 10:24:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
File: backtrace (15.10 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: cgroup (140 bytes, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: core_backtrace (1.28 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: dso_list (7.54 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: environ (1.60 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: limits (1.29 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: maps (36.58 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: open_fds (2.30 KB, text/plain)
2013-07-29 14:14 UTC, Vadim Rutkovsky 		no flags Details
File: proc_pid_status (1.06 KB, text/plain)
2013-07-29 14:15 UTC, Vadim Rutkovsky 		no flags Details
File: var_log_messages (28.51 KB, text/plain)
2013-07-29 14:15 UTC, Vadim Rutkovsky 		no flags Details
Debug.log (428.18 KB, text/plain)
2014-02-19 17:29 UTC, Vadim Rutkovsky 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0419 0 normal SHIPPED_LIVE pulseaudio bug fix and enhancement update 2015-03-05 14:52:57 UTC

Description Vadim Rutkovsky 2013-07-29 14:14:29 UTC 
Description of problem:
Crashed on playing music via bluetooth headset

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

Additional info:
reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        /usr/bin/pulseaudio --start
crash_function: raise
executable:     /usr/bin/pulseaudio
kernel:         3.10.0-2.el7.x86_64
runlevel:       N 5
uid:            1000
xsession_errors: 

Truncated backtrace:
Thread no. 1 (6 frames)
 #2 pa_xmalloc at /lib64/libpulse.so.0
 #3 pa_memblock_new at /usr/lib64/pulseaudio/libpulsecommon-3.0.so
 #4 pa_memchunk_make_writable at /usr/lib64/pulseaudio/libpulsecommon-3.0.so
 #5 pa_sink_render_full at /lib64/libpulsecore-3.0.so
 #6 thread_func at /usr/lib64/pulse-3.0/modules/module-bluetooth-device.so
 #7 internal_thread_func at /usr/lib64/pulseaudio/libpulsecommon-3.0.so
Comment 1 Vadim Rutkovsky 2013-07-29 14:14:33 UTC 
Created attachment 779911 [details]
File: backtrace
Comment 2 Vadim Rutkovsky 2013-07-29 14:14:36 UTC 
Created attachment 779912 [details]
File: cgroup
Comment 3 Vadim Rutkovsky 2013-07-29 14:14:39 UTC 
Created attachment 779913 [details]
File: core_backtrace
Comment 4 Vadim Rutkovsky 2013-07-29 14:14:42 UTC 
Created attachment 779914 [details]
File: dso_list
Comment 5 Vadim Rutkovsky 2013-07-29 14:14:44 UTC 
Created attachment 779915 [details]
File: environ
Comment 6 Vadim Rutkovsky 2013-07-29 14:14:50 UTC 
Created attachment 779916 [details]
File: limits
Comment 7 Vadim Rutkovsky 2013-07-29 14:14:54 UTC 
Created attachment 779917 [details]
File: maps
Comment 8 Vadim Rutkovsky 2013-07-29 14:14:59 UTC 
Created attachment 779918 [details]
File: open_fds
Comment 9 Vadim Rutkovsky 2013-07-29 14:15:02 UTC 
Created attachment 779919 [details]
File: proc_pid_status
Comment 10 Vadim Rutkovsky 2013-07-29 14:15:05 UTC 
Created attachment 779920 [details]
File: var_log_messages
Comment 12 Wim Taymans 2014-02-19 11:14:09 UTC 
This can only be cause by a malloc failure because of pulseaudio's max limit of 96M. I see two scenarios:

1) bluetooth is blocking for a long time and causing pulseaudio to generate a large gap of silence to catch up.

2) bad calculations of elapsed time and written samples causing excessive amounts of data being skipped.

It's unsure what is causing this issue with the provided information.

Is it possible to reliably reproduce this abort?
Comment 13 Vadim Rutkovsky 2014-02-19 11:21:17 UTC 
(In reply to Wim Taymans from comment #12)

> Is it possible to reliably reproduce this abort?
Yes. This happens after bluetooth is being put to sleep and after a minute in this state pulseaudio crashes, so I guess this would be option "1) bluetooth is blocking for a long time and causing pulseaudio to generate a large gap of silence to catch up"
Comment 15 Wim Taymans 2014-02-19 11:34:09 UTC 
(In reply to Vadim Rutkovsky from comment #13)
> (In reply to Wim Taymans from comment #12)
> 
> > Is it possible to reliably reproduce this abort?
> Yes. This happens after bluetooth is being put to sleep and after a minute
> in this state pulseaudio crashes, so I guess this would be option "1)
> bluetooth is blocking for a long time and causing pulseaudio to generate a
> large gap of silence to catch up"

What do you mean with 'bluetooth being put to sleep'? do you turn off the device? does it go into suspend mode?
Comment 16 Vadim Rutkovsky 2014-02-19 11:39:09 UTC 
(In reply to Wim Taymans from comment #15)
> What do you mean with 'bluetooth being put to sleep'? do you turn off the
> device? does it go into suspend mode?
Yes, it seems I can't set bluetooth to stay on in powertop and it is being suspended after several minutes. If I turn off the device pulseaudio behaves correctly.
Comment 17 Wim Taymans 2014-02-19 13:49:15 UTC 
(In reply to Vadim Rutkovsky from comment #16)
> Yes, it seems I can't set bluetooth to stay on in powertop and it is being
> suspended after several minutes. If I turn off the device pulseaudio behaves
> correctly.

That's interesting. Does it suspend even when there is music playing?
Comment 18 Vadim Rutkovsky 2014-02-19 14:33:27 UTC 
(In reply to Wim Taymans from comment #17)
> (In reply to Vadim Rutkovsky from comment #16)
> > Yes, it seems I can't set bluetooth to stay on in powertop and it is being
> > suspended after several minutes. If I turn off the device pulseaudio behaves
> > correctly.
> 
> That's interesting. Does it suspend even when there is music playing?

Yes, it is happens during the playback. Filed bug 1067032 for bluetooth suspend issue. I guess the blocking bug will not let this crash happen.
Comment 19 Wim Taymans 2014-02-19 15:49:06 UTC 
Could you run this, reproduce the problem and attach the generated debug.log file? If this command returns immediately, you should retry (pulseaudio will autostart when killed and then we can't start it with debuging):

killall pulseaudio && pulseaudio -vvvv 2>debug.log
Comment 20 Vadim Rutkovsky 2014-02-19 17:29:16 UTC 
Created attachment 865167 [details]
Debug.log

See attached log.

After I haven't been touching the bluetooth headset buttons the sound was muted (gnome-shell didn't indicate this). Then in 10 minutes pulseaudio crashed

Reproduced on latest available package pulseaudio-3.0-22.el7.x86_64
Comment 21 Vadim Rutkovsky 2014-02-21 13:19:25 UTC 
Blocking issue cannot be reproduced on a different headset
Comment 22 Wim Taymans 2014-02-21 15:59:54 UTC 
Indeed, the poll seems to block for a long time (presumable because the device is suspended) and then it times out and pulseaudio tries to catch up and crashes because it needs too much memory (158MB). I see these solutions:

1) The proper solution would be to fix the suspend bug on the device.

2) The upstream supported solution would be to avoid allocation of memory for skipping data (need to write some new helper functions not sure this is feasable for 7.0 now).

3) A quick workaround would be to limit the amount of data that can be skipped.
Comment 23 Vadim Rutkovsky 2014-02-21 16:28:41 UTC 
*** Bug 1017741 has been marked as a duplicate of this bug. ***
Comment 24 Vadim Rutkovsky 2014-02-21 16:39:18 UTC 
This doesn't seem to be a critical bug, as it depends on (buggy) headset, so I'm gonna report it upstream. A quick workaround for RHEL7 will do, I guess
Comment 25 Wim Taymans 2014-02-24 16:06:31 UTC 
This is a very uncommon bug and I will move a workaround to 7.1.0
Comment 29 Vadim Rutkovsky 2014-12-03 21:59:36 UTC 
I don't have this device anymore, but I guess it would be safe to reproduce this on headsets we have available to verify this
Comment 32 errata-xmlrpc 2015-03-05 10:24:06 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0419.html
Note You need to log in before you can comment on or make changes to this bug.