pulseaudio crashed with SIGABRT in subscribe_callback()

StacktraceTop:
 subscribe_callback (c=<optimized out>, t=<optimized out>, idx=<optimized out>, userdata=<optimized out>) at modules/module-stream-restore.c:1306
 defer_cb (m=<optimized out>, de=<optimized out>, userdata=0xa34160) at pulsecore/core-subscribe.c:174
 dispatch_defer (m=0xa2ea00) at pulse/mainloop.c:704
 pa_mainloop_dispatch (m=0xa2ea00) at pulse/mainloop.c:920
 pa_mainloop_iterate (m=0xa2ea00, block=<optimized out>, retval=0x7fffa54d4414) at pulse/mainloop.c:960

This bug [1] is still reported as present in 3.0, so I tried to track it
down, but I'm not sure what the best fix is. Here's where it crashes:

module-stream-restore.c:
         if (sink_input->save_volume &&
pa_sink_input_is_volume_readable(sink_input)) {
             pa_assert(sink_input->volume_writable);

According to this code, volume_writeable must be true if save_volume is
true. It apparently isn't always so.

But what is the right solution?
  1) Ignore volume_writable, i e, just remove the assertion, or
  2) If volume_writable is false, skip saving the volume, but not mute
and route, or
  3) If volume_writable is false, skip saving the sink input completely

Or, should one
  4) Change everywhere that sets save_volume to "true" to also check for
volume_writable and if so never set save_volume to true?

I'm not sure what the thoughts are behind these two variables, so
looking for advice here.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/896602

This fixes a later assertion failure in module-stream-restore.

Buglink: https://bugs.launchpad.net/bugs/896602
Signed-off-by: David Henningsson <email address hidden>
---
 src/pulsecore/sink-input.c | 3 +++
 src/pulsecore/source-output.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
index 6131bd3..8b9ee72 100644
--- a/src/pulsecore/sink-input.c
+++ b/src/pulsecore/sink-input.c
@@ -376,6 +376,9 @@ int pa_sink_input_new(
         data->save_volume = FALSE;
     }

+ if (!data->volume_writable)
+ data->save_volume = false;
+
     pa_return_val_if_fail(pa_cvolume_compatible(&data->volume, &data->sample_spec), -PA_ERR_INVALID);

     if (!data->muted_is_set)
diff --git a/src/pulsecore/source-output.c b/src/pulsecore/source-output.c
index d942419..96245c7 100644
--- a/src/pulsecore/source-output.c
+++ b/src/pulsecore/source-output.c
@@ -309,6 +309,9 @@ int pa_source_output_new(
         data->save_volume = FALSE;
     }

+ if (!data->volume_writable)
+ data->save_volume = false;
+
     pa_return_val_if_fail(pa_cvolume_compatible(&data->volume, &data->sample_spec), -PA_ERR_INVALID);

     if (!data->volume_factor_is_set)
--
1.7.9.5

On 05/14/2013 11:46 AM, Tanu Kaskinen wrote:
> On Tue, 2013-05-14 at 10:31 +0200, David Henningsson wrote:
>> This bug [1] is still reported as present in 3.0, so I tried to track it
>> down, but I'm not sure what the best fix is. Here's where it crashes:
>>
>> module-stream-restore.c:
>> if (sink_input->save_volume &&
>> pa_sink_input_is_volume_readable(sink_input)) {
>> pa_assert(sink_input->volume_writable);
>>
>> According to this code, volume_writeable must be true if save_volume is
>> true. It apparently isn't always so.
>>
>> But what is the right solution?
>> 1) Ignore volume_writable, i e, just remove the assertion, or
>> 2) If volume_writable is false, skip saving the volume, but not mute
>> and route, or
>> 3) If volume_writable is false, skip saving the sink input completely
>>
>> Or, should one
>> 4) Change everywhere that sets save_volume to "true" to also check for
>> volume_writable and if so never set save_volume to true?
>>
>> I'm not sure what the thoughts are behind these two variables, so
>> looking for advice here.
>
> If volume_writable is false, it doesn't make sense to save the volume,
> because the volume should only be saved when the user sets the volume,
> but the user can't set the volume if it's not writable. So, I think 1 is
> not good. 2 is something that could be considered, but 3 is not. I would
> prefer 4 in some form, but it's bad if every place where save_volume is
> enabled needs to check volume_writable. I think
> pa_sink_input_set_save_volume() would make sense. The function would
> fail if saving the volume is not allowed. The callers could check if the
> function fails, but I don't think that would be necessary in most cases.

Save_volume was not set in very many places, so I believe the just sent
patch would suffice?

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

On 05/15/2013 02:28 PM, David Henningsson wrote:
> This fixes a later assertion failure in module-stream-restore.

There were no comments, so I pushed this one now.

>
> Buglink: https://bugs.launchpad.net/bugs/896602
> Signed-off-by: David Henningsson <email address hidden>
> ---
> src/pulsecore/sink-input.c | 3 +++
> src/pulsecore/source-output.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
> index 6131bd3..8b9ee72 100644
> --- a/src/pulsecore/sink-input.c
> +++ b/src/pulsecore/sink-input.c
> @@ -376,6 +376,9 @@ int pa_sink_input_new(
> data->save_volume = FALSE;
> }
>
> + if (!data->volume_writable)
> + data->save_volume = false;
> +
> pa_return_val_if_fail(pa_cvolume_compatible(&data->volume, &data->sample_spec), -PA_ERR_INVALID);
>
> if (!data->muted_is_set)
> diff --git a/src/pulsecore/source-output.c b/src/pulsecore/source-output.c
> index d942419..96245c7 100644
> --- a/src/pulsecore/source-output.c
> +++ b/src/pulsecore/source-output.c
> @@ -309,6 +309,9 @@ int pa_source_output_new(
> data->save_volume = FALSE;
> }
>
> + if (!data->volume_writable)
> + data->save_volume = false;
> +
> pa_return_val_if_fail(pa_cvolume_compatible(&data->volume, &data->sample_spec), -PA_ERR_INVALID);
>
> if (!data->volume_factor_is_set)
>

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

This bug fix went into PulseAudio 4.0, which is now released into Saucy.

This problem happened while watching a video from youtube.
I was using facebook and the video was in fb page and the browser was mozilla firefox.
Actually it happens sometimes, but I don't know the real reason of this problem.
Because it is not a permanent problem.

I happened again.
This is second same error today.

I mean It happened :)

It happened again.
As I noticed, It happens while listening radio in Rhytymbox.

This problem occurs every day more than 10 times.
I cannot listen a online radio continuously.

kernel ver: 4.3.0-040300rc3-generic

Thanks
Ertan