Start and stop the timers in the data_loop. Otherwise we might be trying
to stop a timer while the data loop is starting it and we end up with
"ready non-active node" messages.
Drivers should only read the target_ values in the timeout, update the
timeout with the new duration and then update the position.
For the position we simply need to add the previous duration to the
position and then set the new duration + rate.
Otherwise, everything else should read the duration/rate and not use
the target_ values.
On glibc, `pthread_t` is `unsigned long int` while on musl
it has a pointer type. To avoid format string warnings,
cast it to `void *` and use the `%p` format specifier.
Add support for using other clocks.
clock.id can be used to set one of the system clocks.
clock.device can be used to open a clock device such as a PTP clock
device.
Use a dll to track the progress of non-monotonic clocks.
A bug was introduced with the refactoring in da26563. In arm_init,
the buffer passed to spa_cpu_read_file is allocated and it is just
going to return that. So cpuinfo will actually point to buffer on
the stack, which need not be freed with a call to free.
The crash resulting with the incorrect free.
root@dragonboard-845c:~# pipewire --version
munmap_chunk(): invalid pointer
[ 185.037284] audit: type=1701 audit(1659949975.843:14): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2243 comm="pipewire" exe="/usr/bin/pipewire" sig=6 res=1
Aborted
root@dragonboard-845c:~# wireplumber --version
munmap_chunk(): invalid pointer
[ 193.453693] audit: type=1701 audit(1659949984.255:15): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2244 comm="wireplumber" exe="/usr/bin/wireplumber" sig=6 res=1
Aborted
Backtrace from the crash
(gdb) bt
!0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
!1 0x0000fffff7d8edd8 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
!2 0x0000fffff7d4a390 in __GI_raise (sig=sig@entry=6) at /usr/src/debug/glibc/2.36-r0/sysdeps/posix/raise.c:26
!3 0x0000fffff7d37498 in __GI_abort () at abort.c:79
!4 0x0000fffff7d83374 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xfffff7e5fc20 "%s\n") at /usr/src/debug/glibc/2.36-r0/sysdeps/posix/libc_fatal.c:155
!5 0x0000fffff7d988c0 in malloc_printerr (str=str@entry=0xfffff7e5a7f0 "munmap_chunk(): invalid pointer") at malloc.c:5660
!6 0x0000fffff7d98aac in munmap_chunk (p=p@entry=0xffffffffd258) at malloc.c:3054
!7 0x0000fffff7d9d068 in __GI___libc_free (mem=mem@entry=0xffffffffd268) at malloc.c:3375
!8 0x0000fffff7cd36cc in arm_init (impl=impl@entry=0xaaaaaaac8c48) at /usr/src/debug/pipewire/1.0-r0/spa/plugins/support/cpu-arm.c:97
!9 0x0000fffff7cd391c in impl_init (factory=<optimized out>, handle=0xaaaaaaac8c48, info=0xffffffffe548, support=<optimized out>, n_support=<optimized out>) at /usr/src/debug/pipewire/1.0-r0/spa/plugins/support/cpu.c:264
!10 0x0000fffff7f3a234 in load_spa_handle (lib=<optimized out>, factory_name=factory_name@entry=0xfffff7f6d768 "support.cpu", info=info@entry=0xffffffffe548, n_support=1,
support=support@entry=0xfffff7fb0488 <global_support+88>) at /usr/src/debug/pipewire/1.0-r0/src/pipewire/pipewire.c:280
!11 0x0000fffff7f3a5b0 in add_interface (factory_name=factory_name@entry=0xfffff7f6d768 "support.cpu", type=type@entry=0xfffff7f62310 "Spa:Pointer:Interface:CPU", info=info@entry=0xffffffffe548,
support=0xfffff7fb0430 <global_support>) at /usr/src/debug/pipewire/1.0-r0/src/pipewire/pipewire.c:358
!12 0x0000fffff7f3b3f8 in pw_init (argc=argc@entry=0xffffffffea5c, argv=argv@entry=0xffffffffea50) at /usr/src/debug/pipewire/1.0-r0/src/pipewire/pipewire.c:661
!13 0x0000aaaaaaaa1104 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/pipewire/1.0-r0/src/daemon/pipewire.c:79
(gdb) f 8
!8 0x0000fffff7cd36cc in arm_init (impl=impl@entry=0xaaaaaaac8c48) at /usr/src/debug/pipewire/1.0-r0/spa/plugins/support/cpu-arm.c:97
97 /usr/src/debug/pipewire/1.0-r0/spa/plugins/support/cpu-arm.c: No such file or directory.
(gdb) info locals
flags = 122
cpuinfo = 0xffffffffd268 "processor\t: 0\nBogoMIPS\t: 38.40\nFeatures\t: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop\nCPU implementer\t: 0x51\nCPU architecture: 8\nCPU variant\t.
line = 0xaaaaaaac8ce0 "\310\252\252\252\n"
buffer = "processor\t: 0\nBogoMIPS\t: 38.40\nFeatures\t: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop\nCPU implementer\t: 0x51\nCPU architecture: 8\nCPU variant\t: 0x7\nCPU pa"...
arch = <optimized out>
__func__ = "arm_init"
When reading the timerfd gives an error, we should return right away
because the timeout did not happen.
If we change the timerfd timeout before reading it, we can get -EAGAIN.
Don't log an error in that case but wait for the new timeout.
We can only write from one thread to the ringbuffer so bypass the
ringbuffer when doing in-thread invoke. Only flush the current
items so that out-of-thread items don't get inserted.
Always append the item to the ringbuffer, even if we are invoking from
the thread itself. This ensure all items are always invoked in the
right order.
If we invoke from the thread, flush all items of the ringbuffer and
return.
Make sure to set the callback to NULL before invoking so that recursive
invoke doesn't call it again.
When while flushing the items we get a recursive invoke, detect this
with a counter and return immediately.
Mostly useful for when invoking from the thread itself so that the new
invoke item is executed before new items are added.
Imagine this case with module-loopback:
- data-loop goes into the capture process function
- mainloop invokes node remove of capture and waits
- data-loop invokes trigger -> node remove is first executed, mainloop
is woken up
- mainloop continues
- mainloop invokes remove of playback and waits
- data-loop continues flushing the ringbuffer -> playback remove is
executed, mainloop wakes up
- mainloop continues destroying items, frees playback
and capture streams
- data-loop finaly gets to flush the trigger and crashes because
streams are gone.
When we try to read one of the events and there was an error, don't
signal the callback. If the error is something else than EAGAIN log
a warning.
Especially for timerfd, EAGAIN can happen when the timer changed
while polling. This can happen when running the profiler because it
polls and updates the timer from different threads.
Register a pthread cleanup handler to guarantee
that `spa_source::{priv, rmask}` are cleared even
if the thread is cancelled while the loop is dispatching.
This is necessary, otherwise `spa_source::priv` could point
to the stack of the cancelled thread, which will lead to
problems like this later:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f846b025be2 in detach_source (source=0x7f845f435f60) at ../spa/plugins/support/loop.c:144
144 e->data = NULL;
[Current thread is 1 (LWP 5274)]
(gdb) p e
$1 = (struct spa_poll_event *) 0x7f845e297820
(gdb) bt
#0 0x00007f846b025be2 in detach_source (source=0x7f845f435f60) at ../spa/plugins/support/loop.c:144
#1 0x00007f846b0276ad in free_source (s=0x7f845f435f60) at ../spa/plugins/support/loop.c:359
#2 0x00007f846b02a453 in loop_destroy_source (object=0x7f845f3af478, source=0x7f845f435f60) at ../spa/plugins/support/loop.c:786
#3 0x00007f846b02a886 in impl_clear (handle=0x7f845f3af478) at ../spa/plugins/support/loop.c:859
#4 0x00007f846b172f40 in unref_handle (handle=0x7f845f3af450) at ../src/pipewire/pipewire.c:211
#5 0x00007f846b173579 in pw_unload_spa_handle (handle=0x7f845f3af478) at ../src/pipewire/pipewire.c:346
#6 0x00007f846b15a761 in pw_loop_destroy (loop=0x7f845f434e30) at ../src/pipewire/loop.c:159
#7 0x00007f846b135d8e in pw_data_loop_destroy (loop=0x7f845f434cb0) at ../src/pipewire/data-loop.c:166
#8 0x00007f846b12c31c in pw_context_destroy (context=0x7f845f41c690) at ../src/pipewire/context.c:485
#9 0x00007f846b3ddf9e in jack_client_close (client=0x7f845f3c1030) at ../pipewire-jack/src/pipewire-jack.c:3481
...
When we leave the last recursive enter of the loop, clear the polling
flag.
It might be possible that it was not cleared because the loop might have
been killed with pthread_kill. In any case, the _leave calls need to be
made in this case as well.
This fixes issues when jack clients stop because it triggers and assert
because the polling flag is still active when the object is cleared.
See !1171
Use `spa_loop_invoke()` to invoke a callback on the data loop
to remove an embedded `spa_source` from the data loop.
Embedded `spa_source` objects cannot be safely removed
while the loop is polling without risking potential
use-after-frees.
The core of the issue is the following: what happens if an
active source is destroyed before it could be dispatched?
For loop-managed sources (`struct source_impl`) this was addressed
by storing all destroyed sources in a list, and only freeing them
after dispatching has been finished. (0eb73f0f06)
This approach works for both strictly single-threaded
and `pw_thread_loop` loops assuming the loop is not
reentered.
However, if the loop is reentered, there can still be issues.
Assume that in one iteration sources A and B are active,
and returned from the system call, and source B is destroyed
before the loop starts dispatching. Consider what happens when
"A" is dispatched first, and it reenters the loop with timeout 0.
Imagine there are no new events, so `loop_iterate()` will immediately
return, but it will first destroy everything in the destroy list
(this is done at the end of `loop_iterate()`).
And herein lies the problem. In the previous iteration,
there exists a `spa_poll_event` object which points to source "B",
but that has just been destroyed at the end of the recursive
iteration. This will trigger a use-after-free once the previous
iteration inspects it.
Fix that by processing the destroy list right after first
processing the returned `spa_poll_event` objects, and
"detach" the source from the loop and its iterations
in `process_destroy()` before the source is destroyed.
See #2114#2147
It may be a little confusing that both the loop object
and the `source_impl` objects are referred to with variables
named `impl`. For this reason, rename all source_impl objects
named `impl` to `s`.
It is expected that `nfds` is non-negative in the vast majority
of cases, so hopefully the runtime performance will not be
significantly affected by removing the check. This way
it is guaranteed that the destroy list is processed.
