When creating a new unit we used to get the system bus via Gio.bus_get_sync,
however this has a singleton implementation, and so would always return the
same connection, creating issues in tests when a new test suite is added
because the newly got connection would be already closed.
So, just manually create a new bus connection, also close the bus and
cleanup the test bus in dbus.
If a device is currently verifying, identifying or enrolling we may want the
user to stop the operation before we actually release the device.
Otherwise we may end-up in trying to close (failing) the internal device,
while fprintd is still considering the device active, causing a dead-lock
(the device can't be released, but neither claimed again or stop the current
action).
In fact calling Claim() -> EnrollStart() -> Release(), we would fail with
the error
net.reactivated.Fprint.Error.Internal:
Release failed with error: The device is still busy with another
operation, please try again later. (36)"
However, if we try to call VerifyStop, after this error, we'd fail because
for the fprintd logic, the device is not claimed anymore, but actually
closed, and we'd need to claim it again, but... That would still cause an
internal error.
To avoid this, in case Relase() is called cancel the ongoing operation,
and wait until it's done before completing the release call.
Instead of automatically replying with the 'whorl' image for every enroll
state signal with result 'enroll-stage-passed', only perform the number
of required enroll stages and ensure that we get the expected results.
This also will allow to manually perform enroll steps in other tests.
Fix CI syntax error:
container_fedora_build: unknown keys in `extends` (.fedora@container-build)
Caused by changes in the wayland CI templates:
4a73f030d0
If we get a `NoEnrolledPrints` error while list, we don't consider it an
hard error and in such case we proceed to releasing the device, but without
clearing the previously set error first.
When starting an identify operation we allocate a gallery of prints from the
gallery, although if we match one of them we get that back in the finish
callback but with a further reference added.
So, in order to clean it up, use an auto-pointer or we'd end up in leaking
it, and the address sanitizer was catching this in our tests already:
Indirect leak of 12020 byte(s) in 5 object(s) allocated from:
#0 0x7fe8bc638ce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
#1 0x7fe8bc37ffd0 in g_malloc0 ../../glib/glib/gmem.c:132
#2 0x55d100635c01 in load_from_file ../src/file_storage.c:159
#3 0x55d100635c01 in file_storage_print_data_load ../src/file_storage.c:182
#4 0x55d10063e950 in fprint_device_verify_start ../src/device.c:882
#5 0x55d10064036b in dbus_glib_marshal_fprint_device_VOID__STRING_POINTER src/device-dbus-glue.h:96
#6 0x7fe8bc50f6f5 (/usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2+0xd6f5)
When using the delete method we check if the device was claimed, if this
fails because the device is already in use we return an error, but we don't
free the user.
While this could be fixed by just a further g_free call, let's just remove
remove the other manual free calls, and use an auto-pointer instead for this
function.
If we get a `NoEnrolledPrints` error during delete, we don't consider it an
hard error and in such case we proceed to releasing the device, but without
clearing the previously set error first.
During delete enrolled fingers2 call, if the check-claimed control fails, we
would return the error without freeing it.
While this could be fixed by just a further g_error_free call, let's just
remove the other manual free call, and use an auto-pointer instead for this
function.
During delete enrolled fingers call, if the check-claimed control fails, and
we get an error different from FPRINT_ERROR_CLAIM_DEVICE, we would return
the error without freeing it.
While this could be fixed by just a further g_error_free call, let's just
remove all the manual free calls, and use an auto-pointer instead for this
function.
In case of early return we may not free them consistently, while this is not
a big problem in a main function, is better to have a cleaner management,
and we did get valgrind reports.
And avoid treating "libdir" as an absolute path, the documentation
clearly states that it is "relative to the prefix".
Based on patch by Timothy Gu <timothygu99@gmail.com>
