Bug 989552
| Summary: | [abrt] pulseaudio-3.0-10.el7: raise: Process /usr/bin/pulseaudio was killed by signal 6 (SIGABRT) | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vadim Rutkovsky <vrutkovs> | ||||||||||||||||||||||||
| Component: | pulseaudio | Assignee: | Wim Taymans <wtaymans> | ||||||||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||
| Version: | 7.0 | CC: | tpelka, vbenes, vrutkovs, wtaymans | ||||||||||||||||||||||||
| Target Milestone: | rc | ||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:a4b1402f096b11fa1e7a227cdac73bb76e554bc2 | ||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||
| Last Closed: | 2015-03-05 10:24:06 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: | |||||||||||||||||||||||||||
| Bug Depends On: | 1067032 | ||||||||||||||||||||||||||
| Bug Blocks: | |||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
|
Description
Vadim Rutkovsky
2013-07-29 14:14:29 UTC
Created attachment 779911 [details]
File: backtrace
Created attachment 779912 [details]
File: cgroup
Created attachment 779913 [details]
File: core_backtrace
Created attachment 779914 [details]
File: dso_list
Created attachment 779915 [details]
File: environ
Created attachment 779916 [details]
File: limits
Created attachment 779917 [details]
File: maps
Created attachment 779918 [details]
File: open_fds
Created attachment 779919 [details]
File: proc_pid_status
Created attachment 779920 [details]
File: var_log_messages
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? (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" (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? (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. (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? (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. 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 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
Blocking issue cannot be reproduced on a different headset 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. *** Bug 1017741 has been marked as a duplicate of this bug. *** 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 This is a very uncommon bug and I will move a workaround to 7.1.0 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 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 |