When we get to this code, we already updated the environment variables
so we need to use the usual error path to restore them.
And where chdir does fail, print an error to the log. 256 chars should
be enough here, if your tmpdir exceeds that you just have the error
message cut off.
You are only supposed to use _insert_new()/_remove() or _insert_at()
on the map, If we detect a _insert_at() to a removed item,
return an error because else we might corrupt the free list.
Update unit test accordingly.
The previous code exposed a race condition, it assumed that our MARK
message was in the next lot of messages by the journal. If something
else would write to the journal in the meantime and our message took
time to arrive, the test would fail.
Fixes#1710
Valgrind tests are running under different conditions than normal tests,
specifically they all run in the same process rather than running one
fork per test. This means one test can affect another test's result if
the test doesn't clean up propertly.
This makes them harder to debug from the logs, so let's give us a
fighting chance by having debug logging enabled.
When running meson test without a preceding ninja build, we end up with
missing libraries. This somehow happened to work until recently but now
it triggers an issue with libspa-dbus.so not being available during the
valgrind test run, causing a test case to fail.
The docs are slightly ambiguous here but it appears a call to
sd_journal_next() is required at least once before the actual data
message.
journalctl positions the cursor with sd_journal_seek_tail() followed by
sd_journal_seek_previous(). The actual enty is then fetched with
sd_journal_next().
Let's do the same here and let's hope this fixes the current race
condition with the test sometimes failing.
Debugging is easier if we can explicitly run a single iteration only.
This filter could be a range but for now it's sufficient to be able to
run a single test only.
Re-using an id after removing it is a bug in the caller but there are
two cases where we corrupt the free list without warning:
Removing an object twice:
id = pw_map_insert_new(object);
pw_map_remove(map, id);
pw_map_remove(map, id);
And inserting an element at an index previously removed:
id = pw_map_insert_new(object);
pw_map_remove(map, id);
pw_map_insert_at(map, id, new_object);
The latter is arguably valid code, or at least it'll look like it's
valid code.
For both cases, check if the id to remove/insert at is a free item and
handle that accordingly.
The Doxygen "Modules" page is not very illuminative, as different parts
of the API are mixed together and not all parts are included.
Try to address this:
Put all parts of the public API to some Doxygen group, usually one group
per header file. Use short, systematic names.
Make these groups sub-groups of a few top-level groups, roughly
corresponding to the different logical parts of the API (core, impl,
stream, filter, spa, utilities).
pw_log_log/logv now go through the topic-based logger using the
"default" topic. Log topics themselves can be allocated by the call
sites. The simplest way to use a topic from e.g. a module:
PW_LOG_TOPIC_STATIC(mod_topic, "mod.foo");
#define PW_LOG_TOPIC_DEFAULT mod_topic
...
void pipewire__module_init() {
PW_LOG_TOPIC_INIT(mod_topic);
...
}
With the #define all pw_log_foo() are now routed through the custom
topic. For the cases where the log topic must be specified, a
pw_logt_foo() set of macros is available.
Log topics are enabled through the PIPEWIRE_DEBUG environment variable
which now supports globs, e.g. PIPEWIRE_DEBUG="*:I;mod.access:D"
to enable global INFO but DEBUG for the access module.
Namespaces documented are "pw", "mod" and "conn", for pipewire-internal
stuff, modules and connection dumping. The latter is special-cased to
avoid spamming the log files, it requires an expcit "conn.<glob>"
pattern to enable.
The "default" topic always exists and is the fallback for any
pw_log_foo() invocation that does not use a topic.
Add a struct spa_log_topic that allows for logical grouping of messages.
The new macros spa_log_logt() and spa_log_logtv() take a topic as
argument, the topic's level acts as filter.
A new macro spa_log_topic_init() initializes a topic. By default a topic
inherits its logger's debug level but a logger implementation may set
that topic to a specific fixed log level.
The various spa_log_*() macros transparently wrap new and old
implementations:
- if the implementation is version 0, the new logt() calls drop the
topic and get routed into the old log() calls
- if the implementation is version 1, the old log() calls use a NULL
topic and get routed into the new logt() calls
All spa_log_* macros use the SPA_LOG_DEFAULT_TOPIC topic (NULL), it is
up to the caller to redefine that. Alternatively, use spa_logt_* to pass
an explicit topic.
There is one crucial flaw in this implementation: log topics are
initialized to their target level by the current logger. Where a topic
is initialized but the logger is switched later, the topic is not
automatically re-initialized. Ultimately this shouldn't matter for
real-world use-cases.
spa_interface_call() and friends will quietly do nothing if the version
doesn't match so we need an extra macro to know whether we can
spa_interface_call() for any given version.
This allows us to implement things like:
if (spa_interface_callback_version_min(1)
spa_interface_call(..., 1, func_v1)
else
spa_interface_call(..., 0, func_v0)
The tests using this function use the pw_log* macros which invoke
whichever logger pipewire has set. Since the default logging
implementation supports logging to a file anyway, let's just use that
instead of having to load the plugin ourselves.
For SPA libraries that we link against elsewhere in the tree, declare a
declare a dependency "foo_dep" for that library that specifies how to
link to it. Then use that dependency in the various targets.
This removes the knowledge of how to link with the library from the
target which can treat it as just another dependency.
In the case of optional libraries (e.g. the journal support lib) we can
then use declare_dependency() to declare an empty dependencies and thus
link them unconditionally in the target.
Allow one of "XEWIDT" to refer to none, errors, warnings, info, debug
and trace, respectively because they're immediately recognizable. Well,
except maybe the X.
PIPEWIRE_DEBUG="I" is equivalent to PIPEWIRE_DEBUG="3" for example.
Running under valgrind enforces --no-fork so any signal will cause valgrind
to error out, failing the test abnormally. This prevents us from running
our test suite through valgrind, we'd have to mark every test specifically
whether it should run under valgrind or not.
Easier is just to automatically skip tests expecting signals.
Mark some structures, arrays static/const at various places.
In some cases this prevents unnecessary initialization
when a function is entered.
All in all, the text segments across all shared
libraries are reduced by about 2 KiB. However,
the total size increases by about 2 KiB as well.
