Bug 989552 - [abrt] pulseaudio-3.0-10.el7: raise: Process /usr/bin/pulseaudio was killed by signal 6 (SIGABRT)
[abrt] pulseaudio-3.0-10.el7: raise: Process /usr/bin/pulseaudio was killed b...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pulseaudio (Show other bugs)
7.0
x86_64 Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Wim Taymans
Desktop QE
abrt_hash:a4b1402f096b11fa1e7a227cdac...
:
: 1017741 (view as bug list)
Depends On: 1067032
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-29 10:14 EDT by Vadim Rutkovsky
Modified: 2015-03-05 05:24 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-05 05:24:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Vadim Rutkovsky 2013-07-29 10:14:29 EDT
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 10:14:33 EDT
Created attachment 779911 [details]
File: backtrace
Comment 2 Vadim Rutkovsky 2013-07-29 10:14:36 EDT
Created attachment 779912 [details]
File: cgroup
Comment 3 Vadim Rutkovsky 2013-07-29 10:14:39 EDT
Created attachment 779913 [details]
File: core_backtrace
Comment 4 Vadim Rutkovsky 2013-07-29 10:14:42 EDT
Created attachment 779914 [details]
File: dso_list
Comment 5 Vadim Rutkovsky 2013-07-29 10:14:44 EDT
Created attachment 779915 [details]
File: environ
Comment 6 Vadim Rutkovsky 2013-07-29 10:14:50 EDT
Created attachment 779916 [details]
File: limits
Comment 7 Vadim Rutkovsky 2013-07-29 10:14:54 EDT
Created attachment 779917 [details]
File: maps
Comment 8 Vadim Rutkovsky 2013-07-29 10:14:59 EDT
Created attachment 779918 [details]
File: open_fds
Comment 9 Vadim Rutkovsky 2013-07-29 10:15:02 EDT
Created attachment 779919 [details]
File: proc_pid_status
Comment 10 Vadim Rutkovsky 2013-07-29 10:15:05 EDT
Created attachment 779920 [details]
File: var_log_messages
Comment 12 Wim Taymans 2014-02-19 06:14:09 EST
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 06:21:17 EST
(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 06:34:09 EST
(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 06:39:09 EST
(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 08:49:15 EST
(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 09:33:27 EST
(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 10:49:06 EST
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 12:29:16 EST
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 08:19:25 EST
Blocking issue cannot be reproduced on a different headset
Comment 22 Wim Taymans 2014-02-21 10:59:54 EST
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 11:28:41 EST
*** Bug 1017741 has been marked as a duplicate of this bug. ***
Comment 24 Vadim Rutkovsky 2014-02-21 11:39:18 EST
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 11:06:31 EST
This is a very uncommon bug and I will move a workaround to 7.1.0
Comment 29 Vadim Rutkovsky 2014-12-03 16:59:36 EST
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 05:24:06 EST
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.