Comment 4 for bug 412677

Daniel T Chen (crimsun) wrote :

Is this crash triggered immediately when you log in, or has audio been playing for a while?

In a Terminal, please use 'killall pulseaudio && pulseaudio -vvvv' as Lennart recommends below. You'll need to check the debug output for the buffer_size value.

Quoting from the e-mail thread on the upstream development mailing list:
On Mon, 17.08.09 08:49, Takashi Iwai (<email address hidden>) wrote:

> At Sun, 16 Aug 2009 18:24:35 -0400,
> Daniel Chen wrote:
> >
> > Hi,
> >
> > In
> > we're debugging an issue where snd_pcm_mmap_begin(), at line 6409 with
> >
> > *offset = *pcm->appl.ptr % pcm->buffer_size;
> >
> > appears to have pcm->buffer_size == 0. What's the correct approach in
> > handling this corner case?
> We could add a sanity check in the function, of course.
> But relying on it doesn't sound nice.
> At least, the caller should be surely at the certain state that the
> buffer has been set up, i.e. checking whether snd_pcm_state() returns
> SETUP or better condition.

Hmm, this bug is triggered in PA apparently. PA doesn't call
snd_pcm_mmap_begin() before the setup finished completely. Not sure
what's going on here, but this smells as if pcm->buffer_size is not
properly initialized.

Daniel, does this happen right-away on PA startup? Or does it
happen sometime while playing?

Could you get us the output of the PA startup phase when running
"pulsaudio -vvvv"? This should show us to which value the buffer_size
is initialized in the snd_pcm_t.