You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Be in a container (pid namespace) where no unwanted dbus-daemon processes are running. (I used a podman container with no dbus-daemon processes at all, but it's OK if the "real" system, session and/or AT-SPI buses are already running.)
Build libportal, then run:
xvfb-run -a -s "-noreset" \
env LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 \
meson test --timeout-multiplier 3 -C obj-x86_64-linux-gnu/
where obj-x86_64-linux-gnu/ is the build directory. (This is how the Debian packaging runs the test suite.)
Expected result
Tests pass. No libportal-related dbus-daemon processes remain running (it's OK if the system, session and/or AT-SPI buses are still running from before).
Actual result with python3-dbusmock 0.29.1-2
The tests pass, but 27 dbus-daemon processes are still running afterwards:
$ pgrep dbus-daem|xargs ps
PID TTY STAT TIME COMMAND
11681 ? Ss 0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_4t6qy
11688 ? Ss 0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_4t6qy
...
11792 ? Ss 0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_81inv
11796 ? Ss 0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_81inv
Actual result with python3-dbusmock 0.30.0-2
The tests fail, with a dbusmock assertion failure:
It appears that dbusmock starts and stops temporary session buses on a per-class basis (they're stopped in tearDownClass()) rather than on a per-test-case basis (they are not stopped in tearDown()). In older versions, starting more than one session bus per DBusTestCase subclass would result in only the last session bus being torn down, with all of the others being leaked. In newer versions, there's an assertion to stop that from happening, so the tests will now just fail.
The text was updated successfully, but these errors were encountered:
smcv
added a commit
to smcv/libportal
that referenced
this issue
Dec 26, 2023
DBusTestCase.start_session_bus() is a class method, and can only be
called once per class, because DBusTestCase.tearDownClass() will only
clean up one session bus. In older versions of dbusmock, calling it more
than once will result in dbus-daemon processes being leaked; since
0.30.0, calling it more than once will result in an assertion failure.
Resolves: flatpak#136
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058245
Signed-off-by: Simon McVittie <smcv@debian.org>
DBusTestCase.start_session_bus() is a class method, and can only be
called once per class, because DBusTestCase.tearDownClass() will only
clean up one session bus. In older versions of dbusmock, calling it more
than once will result in dbus-daemon processes being leaked; since
0.30.0, calling it more than once will result in an assertion failure.
Resolves: #136
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058245
Signed-off-by: Simon McVittie <smcv@debian.org>
Originally reported in a Debian QA rebuild as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058245.
To reproduce
Be in a container (pid namespace) where no unwanted dbus-daemon processes are running. (I used a podman container with no dbus-daemon processes at all, but it's OK if the "real" system, session and/or AT-SPI buses are already running.)
Build libportal, then run:
where
obj-x86_64-linux-gnu/
is the build directory. (This is how the Debian packaging runs the test suite.)Expected result
Tests pass. No libportal-related dbus-daemon processes remain running (it's OK if the system, session and/or AT-SPI buses are still running from before).
Actual result with python3-dbusmock 0.29.1-2
The tests pass, but 27 dbus-daemon processes are still running afterwards:
Actual result with python3-dbusmock 0.30.0-2
The tests fail, with a dbusmock assertion failure:
Root cause
It appears that dbusmock starts and stops temporary session buses on a per-class basis (they're stopped in
tearDownClass()
) rather than on a per-test-case basis (they are not stopped intearDown()
). In older versions, starting more than one session bus perDBusTestCase
subclass would result in only the last session bus being torn down, with all of the others being leaked. In newer versions, there's an assertion to stop that from happening, so the tests will now just fail.The text was updated successfully, but these errors were encountered: