Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#740038: pulseaudio hangs in D (uninterruptible sleep)

46 views
Skip to first unread message

Antoine Beaupré

unread,
Feb 24, 2014, 10:10:02 PM2/24/14
to
Package: pulseaudio
Version: 4.0-6+b1
Severity: important

It is somewhat unclear to me how this happened, but a pulseaudio
daemon has hanged on my machine:

PID STARTED S TTY TIME COMMAND
10093 Feb 21 D ? 01:15:42 /usr/bin/pulseaudio --start --log-target=syslog

I have tried to kill the process (even with -KILL), and it just stays
there. It has been like this for a while now.

I have a rather convoluted setup, with liquidsoap driving pulseaudio,
however liquidsoap is stopped now yet PA is still running. Some
details on the setup can be perused here:

http://anarc.at/services/radio/

I have tried to attach an strace or a gdb to the process, but both
simply hang when attaching.

Here are some relevant logs:

/var/log/syslog.2.gz:Feb 22 11:06:13 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
/var/log/syslog.2.gz:Feb 22 11:06:14 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
/var/log/syslog.2.gz:Feb 22 11:06:23 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
/var/log/syslog.3.gz:Feb 21 17:50:06 marcos pulseaudio[10093]: [pulseaudio] pid.c: Stale PID file, overwriting.
/var/log/syslog.3.gz:Feb 21 19:16:24 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
/var/log/syslog.3.gz:Feb 21 19:16:27 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
/var/log/syslog.1:Feb 23 21:11:21 marcos pulseaudio[10093]: [pulseaudio] module-combine-sink.c: Assertion 'pa_idxset_remove_by_data(o->userdata->outputs, o, NULL)' failed at modules/module-combine-sink.c:927, function output_free(). Aborting.
/var/log/syslog.1:Feb 23 21:11:21 marcos kernel: [796082.449407] CPU: 1 PID: 10093 Comm: pulseaudio Not tainted 3.12-1-amd64 #1 Debian 3.12.9-1

Here is a translation of the french sentence: "Périphérique ou
ressource occupé" means "Resource or device busy" or something to that
effect.

Note that liquidsoap crashed on feb 21st:

2014/02/21 17:44:46 [threads:2] Queue generic queue #2 crashed with exception File "request.ml", line 512, characters 2-8: Assertion failed
2014/02/21 17:44:46 [threads:2] Called from file "duppy.ml", line 280, characters 9-26

2014/02/21 17:44:46 [threads:1] PANIC: Liquidsoap has crashed, exiting..
2014/02/21 17:44:46 [threads:1] Please report at: savone...@lists.sf.net
2014/02/21 17:44:47 >>> LOG START
2014/02/21 17:44:46 [protocols.external:3] Found "/usr/bin/wget".
2014/02/21 17:44:46 [main:3] Liquidsoap 1.1.1

Then it was restarted and it's when that dreaded pulseaudio process
got spawned:

2014/02/21 17:51:44 [threads:3] Created thread "wallclock_pulse" (1 total).
2014/02/21 17:51:44 [clock.wallclock_pulse:3] Streaming loop starts, synchronized by active sources.

I am not sure, however, it was actually writing to that pulseaudio
process at that point. I tried to restart liquidsoap yesterday, but it
failed:

2014/02/23 21:17:01 [clock.wallclock_pulse:2] Error when starting output pulse_out(liquidsoap:): Pulseaudio error: Timeout!
2014/02/23 21:17:01 [threads:3] Created thread "wallclock_pulse" (1 total).
2014/02/23 21:17:01 [clock.wallclock_pulse:3] Streaming loop starts, synchronized by active sources.
2014/02/23 21:17:01 [server:3] Unlink anaradio.socket
2014/02/23 21:17:01 [main:3] Shutdown started!

Notice how it times out talking to pulseaudio.

Other commandline tools also fail to talk to PA:

liquidsoap@marcos:~$ LANG=C pacmd list
Daemon not responding.
liquidsoap@marcos:~$ LANG=C pactl list
Connection failure: Timeout

I understand liquidsoap's pulseaudio implementation may be limited or
wrong, but from my perspective, it shouldn't be crashing the daemon
the way it is doing right now.

I would welcome hints on how to debug this problem, right now I feel
that only a reboot will allow me to kill that process, something which
is a little odd in itself.

-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pulseaudio depends on:
ii adduser 3.113+nmu3
ii consolekit 0.4.6-3+b1
ii libasound2 1.0.27.2-3
ii libasound2-plugins 1.0.27-2+b1
ii libc6 2.17-97
ii libcap2 1:2.22-1.2
ii libdbus-1-3 1.8.0-1
ii libfftw3-single3 3.3.3-7
ii libgcc1 1:4.8.2-15
ii libice6 2:1.0.8-2
ii libltdl7 2.4.2-1.7
ii liborc-0.4-0 1:0.4.18-1
ii libpulse0 4.0-6+b1
ii libsamplerate0 0.1.8-7
ii libsm6 2:1.2.1-2
ii libsndfile1 1.0.25-9
ii libspeexdsp1 1.2~rc1.1-1
ii libstdc++6 4.8.2-15
ii libsystemd-login0 204-7
ii libtdb1 1.2.12-1
ii libudev1 204-7
ii libwebrtc-audio-processing-0 0.1-2
ii libx11-6 2:1.6.2-1
ii libx11-xcb1 2:1.6.2-1
ii libxcb1 1.10-2
ii libxtst6 2:1.2.2-1
ii lsb-base 4.1+Debian12
ii udev 204-7

Versions of packages pulseaudio recommends:
ii gstreamer0.10-pulseaudio 0.10.31-3+nmu2
ii pulseaudio-module-x11 4.0-6+b1
ii rtkit 0.10-3

Versions of packages pulseaudio suggests:
ii paman 0.9.4-1
ii paprefs 0.9.10-1
ii pavucontrol 1.0-1
ii pavumeter 0.9.3-4
ii pulseaudio-utils 4.0-6+b1

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Antoine Beaupré

unread,
Feb 24, 2014, 10:30:01 PM2/24/14
to
Lovely...

A workaround is to do this:

mv .pulse .pulse.old
cp .pulse.old/default.pa .pulse

Of course the old process is still there, but at least the daemon starts
again.

A.

--
Thousands of candles can be lit from a single candle
And the life of the candle will not be shortened.
Happiness never decreases by being shared.
- Buddha

Antoine Beaupré

unread,
Feb 24, 2014, 10:40:02 PM2/24/14
to
So it seems this could not be PA's fault - I actually had a kernel oops
yesterday evening... It could be bad memory but it's the first time I
see such a problem:

[796082.448453] BUG: unable to handle kernel paging request at ffffc90004efe000
[796082.448521] IP: [<ffffffff8127172a>] memmove+0x4a/0x1a0
[796082.448568] PGD 21f027067 PUD 21f028067 PMD 216986067 PTE 0
[796082.448615] Oops: 0002 [#1] SMP
[796082.448642] Modules linked in: rfcomm bluetooth rfkill usblp joydev hid_dr ff_memless ufs nls_utf8 nls_cp437 vfat fat usb_storage snd_hrtimer cpufreq_stats ppdev lp cpufreq_powersave cpufreq_conservative cpufreq_userspace binfmt_misc iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek kvm_intel kvm pcspkr snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_pcm_oss snd_mixer_oss mfd_core snd_pcm evdev snd_page_alloc rng_core snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer parport_pc parport snd asus_atk0110 i915 soundcore video acpi_cpufreq drm_kms_helper drm button processor thermal_sys i2c_algo_bit i2c_core coretemp loop firewire_sbp2 firewire_core crc_itu_t fuse autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq crc32c libcrc32c sha256_ssse3 sha256_generic cbc hid_generic usbhid hid dm_crypt dm_mod sd_mod crct10dif_generic sg sr_mod cdrom crc_t10dif crct10dif_common ata_generic ata_piix libata scsi_mod atl1e ehci_pci uhci_hcd ehci_hcd usbcore usb_common
[796082.449407] CPU: 1 PID: 10093 Comm: pulseaudio Not tainted 3.12-1-amd64 #1 Debian 3.12.9-1
[796082.449457] Hardware name: System manufacturer System Product Name/P5G41-M LE, BIOS 0506 06/11/2010
[796082.449513] task: ffff880215fe17c0 ti: ffff8801a38f0000 task.ti: ffff8801a38f0000
[796082.449559] RIP: 0010:[<ffffffff8127172a>] [<ffffffff8127172a>] memmove+0x4a/0x1a0
[796082.449611] RSP: 0018:ffff8801a38f1ad0 EFLAGS: 00010287
[796082.449645] RAX: ffffc90004efe000 RBX: ffff8800a4f49d40 RCX: 00000000ffffffd7
[796082.449690] RDX: ffffffffffffffe8 RSI: ffffc90004efdff8 RDI: ffffc90004efe000
[796082.449734] RBP: 000000000000011a R08: 534547415353454d R09: 5f434c2f72662f65
[796082.449778] R10: 6c61636f6c2f6572 R11: 6168732f7273752f R12: 00000000ffffffd8
[796082.449822] R13: ffffc90004efaa80 R14: 0000000000000028 R15: ffffc90004efe028
[796082.449867] FS: 00007ff540460740(0000) GS:ffff88021fc80000(0000) knlGS:0000000000000000
[796082.449916] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[796082.449953] CR2: ffffc90004efe000 CR3: 00000001c7402000 CR4: 00000000000407e0
[796082.449997] Stack:
[796082.450011] ffffffff811c134c ffffc90004ef9000 ffffc90004efad98 ffff8801a38f1d10
[796082.450067] ffff880094d0aec0 ffff880000001d98 ffffffff81824460 ffff880200005000
[796082.450122] ffff88000000013d 0000013d00000000 0000000000001d98 ffff880215fe17c0
[796082.450177] Call Trace:
[796082.450200] [<ffffffff811c134c>] ? elf_core_dump+0x9ac/0x1390
[796082.450252] [<ffffffffa02aab3d>] ? __ext4_journal_stop+0x2d/0x80 [ext4]
[796082.450296] [<ffffffff811afcde>] ? fsnotify+0x24e/0x330
[796082.450333] [<ffffffff811c87fb>] ? do_coredump+0xa0b/0xd90
[796082.450372] [<ffffffff8106c050>] ? get_signal_to_deliver+0x1c0/0x5b0
[796082.450415] [<ffffffff8101235d>] ? do_signal+0x3d/0x5b0
[796082.450450] [<ffffffff8106b17f>] ? do_send_sig_info+0x4f/0x70
[796082.450488] [<ffffffff81012938>] ? do_notify_resume+0x68/0x90
[796082.450527] [<ffffffff81499272>] ? int_signal+0x12/0x17
[796082.450560] Code: 00 00 48 81 fa a8 02 00 00 72 05 40 38 fe 74 41 48 83 ea 20 48 83 ea 20 4c 8b 1e 4c 8b 56 08 4c 8b 4e 10 4c 8b 46 18 48 8d 76 20 <4c> 89 1f 4c 89 57 08 4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4
[796082.450833] RIP [<ffffffff8127172a>] memmove+0x4a/0x1a0
[796082.450871] RSP <ffff8801a38f1ad0>
[796082.450895] CR2: ffffc90004efe000
[796082.452927] ---[ end trace 71e1f157bace73b5 ]---

796082 is 2014-02-23T21:11:20Z-5

--
That's the kind of society I want to build. I want a guarantee - with
physics and mathematics, not with laws - that we can give ourselves
real privacy of personal communications.
- John Gilmore
0 new messages