Attempts to workaround a race condition between daemon thread and
GDBus worker thread during shutdown.
Ubuntu bug: https://bugs.launchpad.net/bugs/2127049
I've not been able to get a symbolic backtrace yet or reproduce it
myself, but the behaviour points to a threading bug. Hypothesis,
Main thread (1, daemon thread) shuts down, unregistering its plugins.
One of the plugins, module-permissions-portal, is triggered to
shutdown.
It tries to clear its GDBus connection handle without disconnecting
its signal handlers.
GDBus thread (2) is in the middle of writing a message on the same
connection handle.
Once finished, it also tries to clear its handle.
The main thread has already taken the signal lock and the signal
handler table ends up in an invalid state, triggering the assert.
I believe this could happen since
wp_portal_permissionstore_plugin_disable is not disconnecting its
signal handlers before trying to clear its DBus object.
See https://bugzilla.gnome.org/show_bug.cgi?id=730296 for more
discussion about this assert in the Glib signal handling code.
If we re-configure the adapter with different settings than the ones from the
first configuration, we also need to configure the node ports to make sure they
are updated with the new settings.
For example, this is needed for stream audio adapters that have been configured
with monitor ports, and later re-configured without monitor ports. Without this
change, since stream audio adapters never configure the node ports on activation,
the internal node will still have the monitor ports present even after disabling
them in the 2nd re-configuration.
Voice calls can require special audio routing to work, such as by
switching the profile or opening an audio stream. Add a module to
monitor for the starting and stopping of a voice call.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
The only secure and robust way to check that a userdata is of the
expected type is to check its metatable. Userdata metatables are not
changeable by Lua code without the debug library, so if the metatable is
a certain table, only C code could have made it so. GLib type checking
functions are _not_ a robust or secure way to check that a block of
memory is a specific type of GObject, because Lua code could cause a
type confusion bug and potentially use it to forge pointers.
These builders had many bugs:
1. They would longjmp() across the destructor of a g_autoptr() if a Lua
error was thrown. This will leak the memory in the g_autoptr()
unless Lua is compiled with C++ exceptions.
2. They depended on the iteration order of numerical keys in Lua tables.
Lua explicitly does not specify this order.
3. They would produce nonsensical SPA POD array or choice types with
strings or bytes as values. These would cause undefined behavior if
manipulated by naive C code, or assertion failures if
spa_pod_is_array() and spa_pod_is_choice() are modified to check that
the contents of arrays and choices have sensible types.
4. They silently accepted extra arguments, potentially causing confusion
and making it harder to extend the functions in a
backwards-compatible way.
Solve the first problem by calling functions that can raise a Lua error
in a protected environment (with lua_pcall). If there is a Lua error,
rethrow it after the g_autoptr() destructor has run.
Solve the second problem by first obtaining the number of keys in the
table and then iterating over the keys that are expected to be present.
If any of the keys are not contiguious integers starting at 1, the range
[1..number of keys] will include a number that is not a table key. This
will result in lua_rawgeti pushing a nil onto the Lua stack. An
explicit check throws a useful error in this case.
Solve the third problem by explicitly checking that the type is
reasonable before building an array or choice. If it is wrong,
a Lua error is thrown.
Solve the fourth problem by using luaL_checktype (L, 2, LUA_TNONE) to
check that no unwanted values were passed. The C function called with
lua_pcall is passed every argument passed by Lua, followed by a light
userdata that stores a context pointer. After the light userdata is
popped from the Lua stack, the Lua stack is identical to what Lua
created when it called the outer C function, so the type-checking
functions in the auxillary library can be used to enforce that only the
correct number and type of arguments were passed.
Lua provides "extra data", which is some memory in each Lua state that
the application can use for its own purposes. Use this to store the
reference count.
When a new Format param is set, the node's state is not checked, so this
attempt can even take place when the node is not suspended. Setting that
param will not work if the node isn't suspended though. Add a check for
the state and suspend the node if needed.
Also, do not set the Format param if the new param POD is the same as that
of the existing format to avoid redundant calls.
(This mirrors already existing checks for the PortConfig param.)
Cancel the async calls that get the name of the application owning the
service, when WpReserveDevice is finalized or we are going to make
another call.
Fixes UAF accessing self when the async callback runs.
`wp_dbus_connection_disable()` creates a new GCancellable
object at the end, which is never freed if the GObject
is then destroyed. To fix this, override `finalize()` and
clear everything there as well.
Direct leak of 64 byte(s) in 1 object(s) allocated from:
0 0x70e688efd1aa in calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x70e6874b3e62 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x63e62) (BuildId: 7b781c8d1a6e2161838c5d8f3bd797797c132753)
2 0x70e6875dea75 in g_type_create_instance (/usr/lib/libgobject-2.0.so.0+0x3ea75) (BuildId: 5af5e0f7d0a900ecb6083fbd71e22e5522d872e2)
3 0x70e6875c3804 (/usr/lib/libgobject-2.0.so.0+0x23804) (BuildId: 5af5e0f7d0a900ecb6083fbd71e22e5522d872e2)
4 0x70e6875c4e7e in g_object_new_with_properties (/usr/lib/libgobject-2.0.so.0+0x24e7e) (BuildId: 5af5e0f7d0a900ecb6083fbd71e22e5522d872e2)
5 0x70e6875c5ed1 in g_object_new (/usr/lib/libgobject-2.0.so.0+0x25ed1) (BuildId: 5af5e0f7d0a900ecb6083fbd71e22e5522d872e2)
6 0x70e684d2a8a6 in wp_dbus_connection_disable ../subprojects/wireplumber/modules/module-dbus-connection.c:173
7 0x70e688a833cc in wp_plugin_deactivate ../subprojects/wireplumber/lib/wp/plugin.c:144
8 0x70e688a7126c in wp_object_deactivate ../subprojects/wireplumber/lib/wp/object.c:542
9 0x70e688a6e74e in wp_object_dispose ../subprojects/wireplumber/lib/wp/object.c:191
10 0x70e6875c0f6c in g_object_unref (/usr/lib/libgobject-2.0.so.0+0x20f6c) (BuildId: 5af5e0f7d0a900ecb6083fbd71e22e5522d872e2)
11 0x70e6841f7d6d in wp_portal_permissionstore_plugin_disable ../subprojects/wireplumber/modules/module-portal-permissionstore.c:207
12 0x70e688a833cc in wp_plugin_deactivate ../subprojects/wireplumber/lib/wp/plugin.c:144
[...]
If the user is reported as active then check that they have at
least one active seat and downgrade the status to online if not.
This ensures that a remote login session won't be interpreted as
the user being active on a local seat.
Make decision on whether to show code location in journal messages based
on whether the WpLogTopic would enable DEBUG level messages.
Add wp_logt_checked API to take WpLogTopic as input to make this
possible, and deprecate wp_log_checked.
Given that we are allowing Conf() to instantiate a new WpConf,
the methods on the class need to be callable in reference to Self while
maintaining API compatibility with being indexable from the table as a
static method.
Allow this by checking if the first argument passed in is userdata.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
This exposes the ability to load a SPA-JSON representation of a WpConf
object from an arbitrary file on disk to the Lua API
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Global class identifiers, such as "Node", "SessionItem", "Conf", etc
are so far defined either as methods, which are constructors for
the GObject class, or as tables, which contain "static" methods, i.e.
methods that can be called without an instance.
In some cases, we may want to mix a class being both instantiatable
with a constructor and also have static methods. To support this,
allow the class identifier be declared as a table with the constructor
being defined as the "__new" method. This change allows calling the
table as a method and execute "__new" underneath.
For instance:
```
json = Conf.get_section_as_json("foobar") -- static method
conf = Conf("/foo/bar") -- constructor, equivalent to Conf.__new("/foo/bar")
```
See also !629
These errors are propagated to the caller, so it's the caller's
responsibility to print them appropriately, if necessary. Printing
a notice also here is only confusing.
A debug mesage is still be useful for developers to understand the flow.
The wp_settings_delete_all() API internally uses wp_metadata_clear() to clear
all the keys in the persistent-sm-settings metadata object. This call emits
the metadata changed signal with both 'key' and 'value' set to NULL. When that
happens, we need to clear all settings from the state file.
It is possible that a node is destroyed while the select-target
event is ongoing. In that case, the next hook to run will likely crash.
Fix this by cancelling events automatically when their subject
is a session-item associated with a node, as soon as the node is destroyed.
See !619
Reset back to the session item's "configured" state instead of clearing
the si properties completely. This allows the "session-item-removed"
event to be dispatched with all the original properties of the node
intact, for constraint matching purposes.
Fixes#588
Cache the rules in a global variable in each script, as JSON,
and use JsonUtils directly to evaluate them. This will allow us to
close the WpConf in the future after loading the scripts.
Also change the order of the return values of the match_rules_apply_properties
function to be able to easily ignore the number of changed values,
which is useless in most cases.
In some cases we need to get a section as JSON, so that we can pass it
down to the rules parser, while in other cases we neeed to get it as a
table to use it natively, and in that case we even need to differentiate
between it being an object, an array or an object with WpProperties.
Make it also possible to optionally pass tables with default values to
the functions so that we can get rid of cutils.get_config_section()
as well.
We do not use these APIs, so there's no point in keeping them.
Realistically, every component that needs a section just does its
own parsing on it, so the _get_value() functions are not needed.
The fallback in _get_section() is also not needed, as we always
pass NULL and then test for it. In Lua, however, it seems we are
using the fallback to return an empty object, so that getting
a section does not expand to multiple lines of code. For that reason,
I have kept the syntax there and implemented it in the bindings layer.
Changes:
- Configuration files are no longer located by libpipewire,
which allows us to control the paths that are being looked up.
This is a requirement for installations where pipewire and
wireplumber are built using different prefixes, in which case
the configuration files of wireplumber end up being installed in
a place that libpipewire doesn't look into...
- The location of conf files is now again $prefix/share/wireplumber,
/etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using
the pipewire directories. Also, since the previous commits, we now
also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber)
and $XDG_DATA_DIRS/wireplumber for system-wide configuration.
- Since libpipewire doesn't expose the parser, we now also do the
parsing of sections ourselves. This has the advantage that we can
optimize it a bit for our use case.
- The WpConf API has changed to not be a singleton and it is a
property of WpCore instead. The configuration is now expected
to be opened before the core is created, which allows the caller
to identify configuration errors in advance. By not being a singleton,
we can also reuse the WpConf API to open other SPA-JSON files.
- WpConf also now has a lazy loading mechanism. The configuration
files are mmap'ed and the various sections are located in advance,
but not parsed until they are actually requested. Also, the sections
are not copied in memory, unlike what happens in libpipewire. They
are only copied when merging is needed.
- WpCore now disables loading of a configuration file in pw_context,
if a WpConf is provided. This is to have complete control here.
The 'context.spa-libs' and 'context.modules' sections are still
loaded, but we load them in WpConf and pass them down to pw_context
for parsing. If a WpConf is not provided, pw_context is left to load
the default configuration file (client.conf normally).
This adds support for the system-wide locations for configuration and
data files, as defined by the XDG Base Directory Specification.
In addition, it adds two flag groups, CONFIGURATION and DATA, to the
base-dirs system, so that we don't have to hard-code the combinations
of flags everywhere.
Instead, make it so that WIREPLUMBER_*_DIR environment variables can
contain a list of directories to look into. This is safer and,
as a bonus, allows for more control over the lookup directories.
Using the G_TEST_SRCDIR variable can cause problems for tests of other
projects that use libwireplumber and may also lead to unexpected
behavior by not being obvious that this causes wireplumber to skip
looking in its standard directories...
This also brings back WIREPLUMBER_CONFIG_DIR, which is going to be
needed again for the upcoming WpConf changes.
