[pulseaudio-discuss] What could cause "Assertion '!e->next' failed at pulsecore/queue.c:104, function pa_queue_pop(). Aborting." ?

[wellington wallace]

On Sat, Mar 24, 2018 at 12:42 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:

> On Fri, 2018-03-23 at 15:38 -0300, wellington wallace wrote:
> > Hi! PulseEffects developer here.
> >
> > Every now and then when my applications starts it crashes with:
> >
> > Assertion '!e->next' failed at pulsecore/queue.c:104, function
> > pa_queue_pop(). Aborting.
> >
> > This error is one of those that almost never happens and when it does it
> > has no obvious reason. What could be causing this? As I am talking to
> > Pulseaudio from Python it is possible I am doing something wrong in this
> > communication. But as this error means nothing to me I don't know where
> to
> > look.
>
> I don't recall seeing this specific error, but a low-level data
> structure corruption suggests a concurrency bug. If your application
> were a C program, it should not access pa_mainloop, pa_context,
> pa_stream etc. objects from multiple threads, unless locking is
> appropriately implemented with pa_threaded_mainloop. I'm not familiar
> with the Python bindings, so I'm not sure how helpful this is to you.
> Does your application have multiple threads? It could also be that the
> Python bindings are buggy.
>
>
Hi Tanu,

I wrote the python bindings I am using in PulseEffects. Although I doubt
they are perfect I think your point about the wrong use of multiple threads
is probably the source of the problem. Last night I was reading Pulseaudio
api guide again and I realized I was doing something wrong when waiting for
operations completion. For some reason I was doing:

while (pa_operation_get_state(o) == PA_OPERATION_RUNNING):
        pass

instead of

while (pa_operation_get_state(o) == PA_OPERATION_RUNNING):
        pa_threaded_mainloop_wait(main_loop)

and the lock/unlock mechanism explained in the docs. I
use pa_operation_get_state when waiting for the null sinks to be loaded.
Every now and then PulseEffects got stuck when waiting for these sinks.
Maybe both problems have my api misuse as source.

Changing a little of subject. What would be the proper way to show the user
the current latency-time and buffer-time of sink inputs?  Right now I am
updating these values when there is a "change event" on the sink inputs.
But I noticed that changes in latency or buffer does not trigger this
signal like volume or cork state changes do.

Best regards,

                  Wellington

-- 
Prof.° Wellington Wallace Miguel Melo

CEFET/RJ Uned Nova Iguaçu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180324/4bf84f7c/attachment-0001.html>