`(n_items) + 1 * sizeof(*items)` is not the correct size to allocate
for `n_items + 1` count of objects each with size `sizeof(*items)`,
the `+ 1` should be inside the parentheses.
Fixes#4481
Fixes: 4baa94fce2 ("thread: make it possible to set a custom create function")
Both `spa_rectangle` and `spa_fraction` store unsigned numbers,
so print them as unsigned, the same way it is already done in
`spa_debug_strbuf_format_value()`.
Since fc49c1697a ("context: improve negotiation") it is possible
that the out parameter `format` will be set to `filter`. However,
`filter` is a SPA POD from the local SPA POD builder `fb`, which
references the local buffer `fbuf`.
In those cases, if the callers then make use of the returned SPA POD,
a stack use-after-free happens, such as the one displayed below.
The issue could be reliably triggered by executing the `video-play`
example program, and then trying to use the same camera in firefox.
As seen below, the input node, firefox's, provides no format preference,
causing the output format to be used. Previously, this had led
to the use-after-free described above.
pw.link | [impl-link.c: 130 link_update_state()] (46.0.1 -> 114.0.0) init -> negotiating (paused-configure)
pw.context | [ context.c: 935 pw_context_find_format()] 0x51e000000080: finding best format 3 1
pw.context | [ context.c: 943 pw_context_find_format()] 0x51e000000080: states 3 1
pw.context | [ context.c: 958 pw_context_find_format()] 0x51e000000080: Got output format:
pw.context | [ context.c: 959 pw_context_find_format()] video/raw
pw.context | [ context.c: 959 pw_context_find_format()] format : (Id) YUY2
pw.context | [ context.c: 959 pw_context_find_format()] size : (Rectangle) 640x480
pw.context | [ context.c: 959 pw_context_find_format()] framerate : (Fraction) 30/1
pw.context | [ context.c: 966 pw_context_find_format()] 0x51e000000080: no input format filter, using output format: Success
=================================================================
==418404==ERROR: AddressSanitizer: stack-use-after-return on address 0x73993ee46200 at pc 0x739941d31020 bp 0x7fff526b4670 sp 0x7fff526b4660
READ of size 4 at 0x73993ee46200 thread T0
#0 0x739941d3101f in spa_pod_builder_raw ../spa/include/spa/pod/builder.h:150
#1 0x739941d3b35d in do_negotiate ../src/pipewire/impl-link.c:294
#2 0x739941d46214 in check_states ../src/pipewire/impl-link.c:727
#3 0x739941f14405 in process_work_queue ../src/pipewire/work-queue.c:64
#4 0x73993d0dbe99 in source_event_func ../spa/plugins/support/loop.c:894
#5 0x73993d0d6881 in loop_iterate ../spa/plugins/support/loop.c:727
#6 0x739941d76b05 in spa_loop_control_enter ../spa/include/spa/support/loop.h:264
#7 0x739941d76d93 in spa_loop_control_leave ../spa/include/spa/support/loop.h:268
#8 0x739941d78946 in pw_main_loop_quit ../src/pipewire/main-loop.c:109
#9 0x5a64b3cb1cec in main ../src/daemon/pipewire.c:130
#10 0x739940c34e07 (/usr/lib/libc.so.6+0x25e07) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3)
#11 0x739940c34ecb in __libc_start_main (/usr/lib/libc.so.6+0x25ecb) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3)
#12 0x5a64b3caf3b4 in _start (/pipewire/build/src/daemon/pipewire+0x173b4) (BuildId: f9e8403a377e28bf8bd9cf0a5b89d33f08499917)
Address 0x73993ee46200 is located in stack of thread T0 at offset 512 in frame
#0 0x739941c6ed5e in pw_context_find_format ../src/pipewire/context.c:907
This frame has 15 object(s):
[...]
[432, 480) 'fb' (line 911)
[512, 4608) 'fbuf' (line 912) <== Memory access at offset 512 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return ../spa/include/spa/pod/builder.h:150 in spa_pod_builder_raw
[...]
Fixes: fc49c1697a ("context: improve negotiation")
Don't hide pulsedeviceprovider so pulsesink/src are listed by the device provider
and exclude pipewire's audio devices in its deviceprovider.
Continue showing video devices in pipewiredeviceprovider, so that pipewiresrc is
listed for the video devices
Make sure we copy the DSP functions in the convolver before leaving the
function because we need them to clear memory.
Don't store the DSP functions in the head and tail convolvers but pass
them from the main convolver because the convolvers might be NULL but we
still need the DSP functions to clear memory.
Fixes#4433
If the PCM is loaded directly using only api.alsa.path,
state->card_index may never be initialised, and then we end up opening
the wrong ctl device. Let's try a fallback for this case.
Don't use %f to serialize floats to JSON but use the json formatter
because in some locales, the decimal point becomes a , which does not
parse as a float anymore.
Also reformat some lines.
Fixes#4418
When we don't support EXPBUF according to the probe, the host will
allocate memory for us. We will then try to use USERPTR to import the
memory into v4l2.
If this is not supported, try to fall back to MMAP support, mmap the
buffers and memcpy the MMAP buffer to the host allocated buffers.
Instead of just probing with 2 buffers, probe with the MAX_BUFFERS and
remember how many buffers we received.
Some drivers (v4l2loopback) work with less than MAX_BUFFERS (8) and we
need to set the max number of buffers in the Buffers param.
When the driver starts, save all previous node timestamps, not just the
previous signal time.
For async nodes, uses the previous timestamps in the profiler messages
so that we get stats with 1 cycle of delay instead of bogus values
because the node is still processing.
Fixes pw-top for async nodes.
When the driver node is destroyed (like when unplugging the cable) it
will drop/pause all of the follower ALSA nodes. This is something that
happens internally because of how the ALSA nodes work together, on the
PipeWire level, the nodes are still running and they will just be moved to
another driver.
The problem is that nothing will then start the nodes again after moving
it to the new driver. Fix this by keeping track of the desired target
state of the ALSA node and restoring that state when we detect that we are
paused when moved to a new driver.
Fixes#4401
The src can listen to RequestProcess commands and so gets the
node.supports-request = 1 property.
The play-pull example can both be a driver that listens to
RequestProcess or a lazy driver so set this in properties as well.
We can now remove the priority.driver property because automatic
priority selection will make us a driver or not.
With this change, video-src to video-play-pull will use lazy scheduling
with play-pull as the driver. video-play-pull to v4l2src will use
normal scheduling and video-src to video-play will also use normal
scheduling.
Collect the request scheduling flags and when there is a lazy driver,
set the lazy scheduling flag in its clock. This means that the driver
can expect RequestProcess commands to start the scheduling.
Pass the lazy scheduling clock flag to the node.
Make sure lazy scheduling driver have a higher priority than their
request drivers.
Make a plugin structure that is dynamically allocated for each plugin
and pass it around to the descriptor instance structures, so that they
all have access to dsp_ops without sharing a static pointer.
The problem with the static pointer is that the dsp_ops structure is
actually allocated in module-filter-chain's instance structure,
so it always points to the instance of the last filter-chain that was
loaded in the process. When this is unloaded, the other filter-chains
crash.
Take the current cycle times early and in all cases. We can use this to
get the current frame time for debugging purposes instead of the more
heavy jack_frame_time().
Rate limit the xrun warnings.
Iterate the channels in the inner loop instead of the outer loop. This
makes it handle with 0 channels better but also does the more
complicated phase increment code only once for all channels. Also the
filters might stay in the cache for each channel now.
Client-side bugs calling methods on destroyed proxies like
pw_proxy_ref(p);
pw_proxy_destroy(p);
...
wait for server to ack the remove
...
pw_core_destroy(p->core, p); /* p already removed & destroyed */
should not send messages with the stale proxy id to server.
Set id to SPA_ID_INVALID when removing a proxy from the id map, so that
such client bugs only result to ENOENT.
First make instances of all the plugins and then try to link them up.
Otherwise, depending on the order the plugins are defined in the config,
a link will try to create port data and set it on the instance, which is
still NULL and we crash.
