One peculiar thing about the backtrace is that softvol is being used in alsa. So that's one candidate where the bug might be instead of pulseaudio code.

The user didn't enable softvol himself. ~/.asoundrc or /etc/asound.conf don't exist. Presumably softvol is enabled by the stock alsa configuration for the "front" device. It could be tried if removing "front:%f" from the device-strings of the analog-stereo mapping helps. We tried that already, but it was removed only from profile-sets/default.conf, which didn't seem to have any effect ("front:0" was still opened according to the logs), so I think actually profile-sets/extra-hdmi.conf was being used.

The user, "ruler501", had to start doing something else, but he said that he'd come back tomorrow to irc, so further debugging can be done at that point.

Additional information: The distro is Sabayon Linux, and alsa-lib version is 1.0.25-r1.

Another bit of information:

<ruler501> these problems just started today but I haven't done any updates or editted anything relating to pulse/alsa if that helps at all


It sounds unlikely that code would start reliably crashing without changing anything, though...

Forgot to add this: removing "front:%f" from extra-hdmi.conf did the trick: no more crashing observed. So, the problem seems to occur only with softvol. Maybe this is an alsa bug.

I've also ran into the same issue - crash in sndpcm_area_silence(), running Gentoo ~amd64. In my case though the problem was isolated to a particular application, ie. other apps would work fine but rhythmbox would end up crashing pulseaudio.

Using the workaround from Comment 4, removing "front:%f" from extra-hdmi.conf I was able to get rhythmbox to play songs without crashing pulseaudio, however I noticed that rhythmbox's volume was 0 on pavucontrol. After bumping the volume level up I was able to hear the music being played. What is even more curious though, is that I reverted the change to extra-hdmi.conf, restarted pulseaudio and rhythmbox was STILL working.

This leads me to believe that this bug may have something to do with the per-application volume level getting somehow messed up.

(In reply to comment #5)
> I've also ran into the same issue - crash in sndpcm_area_silence(), running
> Gentoo ~amd64. In my case though the problem was isolated to a particular
> application, ie. other apps would work fine but rhythmbox would end up crashing
> pulseaudio.
> 
> Using the workaround from Comment 4, removing "front:%f" from extra-hdmi.conf I
> was able to get rhythmbox to play songs without crashing pulseaudio, however I
> noticed that rhythmbox's volume was 0 on pavucontrol. After bumping the volume
> level up I was able to hear the music being played. What is even more curious
> though, is that I reverted the change to extra-hdmi.conf, restarted pulseaudio
> and rhythmbox was STILL working.
> 
> This leads me to believe that this bug may have something to do with the
> per-application volume level getting somehow messed up.

I find it unlikely that the problem is in the per-application volumes as such.

If you have only one stream playing, and its volume is at 0, the hardware volume will also be set to zero (if flat volumes are enabled, like they are by default). So, could it be that the crash happens only when alsa's softvol is used with zero volume? Can you reproduce the crash by setting rhythmbox volume to 0 again?

Yes, right on. Setting the rhythmbox volume to 0 in pavucontrol (while it was playing) immediately crashed pulseaudio.

Same issue.
I have it when alsa-lib (1.0.25) compiled (gcc 4.6.3) with -O3 or -ftree-vectorize

Created attachment 66377 [details]
valgrind log

valgrind --trace-children=yes /usr/bin/pulseaudio

alsa-lib compiled with -O1 --ftree-vectorize

I've had this problem too and the problem only occurs with -ftree-vectorize.

It looks to me as if this is a gcc bug, as it produces a "movdqa" or "vmovdqa" instruction which is used with an unaligned pointer.

Now, I have no clue why gcc assumes the pointer would be an aligned one, maybe it is even right and something else is wrong, but I haven't spent too much time digging into this.

(note that it still happens with gcc 4.7 and the current 4.8 development one)

Also, this bug should probably be brought up with the alsa guys as well, as I don't think pulseaudio is at fault here.

(In reply to comment #10)
> Also, this bug should probably be brought up with the alsa guys as well, as
> I don't think pulseaudio is at fault here.

You're right. I sent a mail to alsa-devel: http://thread.gmane.org/gmane.linux.alsa.devel/102097

alsa-lib-1.0.27.2, gcc-4.9 with -O3. I can confirm this issue.

*** Bug 98597 has been marked as a duplicate of this bug. ***

This seems to be still affecting people (see bug 98597). I'm marking this as a release blocker, even though the bug seems to be in alsa. Reporting this to alsa-devel didn't have any effect last time it was tried. Maybe we can figure this out ourselves.

Here's a working link to the mail that got no responses:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-October/056288.html

I realized that it makes no sense to have this as a release blocker, because the fix wouldn't be part of the release anyway, since we're releasing pulseaudio, not alsa-lib. Nevertheless, I'll keep this prioritized high on my todo list.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/464.