1. 17 Mar, 2020 8 commits
    • Marco Trevisan's avatar
      device: Cancel the ongoing operation when releasing the device · e7f804e9
      Marco Trevisan authored
      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.
      e7f804e9
    • Marco Trevisan's avatar
      device: Return 'verify-no-match' on cancelled verification · 0e993d92
      Marco Trevisan authored
      We were returning a 'verify-unknown-error' while we actually know what
      happened, so better to return a soft operation failure.
      0e993d92
    • Marco Trevisan's avatar
      device: Return 'enroll-failed' on cancelled enrollment · b312a5e5
      Marco Trevisan authored
      We were returning an 'enroll-unknown-error' while we actually know what
      happened, so better to return a soft operation failure.
      b312a5e5
    • Marco Trevisan's avatar
      tests/fprintd: Verify that each enroll stage happens · c12778ec
      Marco Trevisan authored
      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.
      c12778ec
    • Marco Trevisan's avatar
      dbabd4d7
    • Marco Trevisan's avatar
      db1865eb
    • Bastien Nocera's avatar
      ci: Fix unknown keys in CI · 10a3e759
      Bastien Nocera authored
      Fix:
      root config contains unknown keys: container_fedora_build
      10a3e759
    • Bastien Nocera's avatar
      ci: Fix CI syntax error · 01ea517a
      Bastien Nocera authored
      Fix CI syntax error:
      container_fedora_build: unknown keys in `extends` (.fedora@container-build)
      Caused by changes in the wayland CI templates:
      wayland/ci-templates@4a73f030
      01ea517a
  2. 19 Feb, 2020 1 commit
  3. 18 Feb, 2020 2 commits
  4. 14 Feb, 2020 10 commits
    • Marco Trevisan's avatar
      main: Improve comments on fprint manager creation · 52e12459
      Marco Trevisan authored
      Explain why the manager creation is async better in both in the main file
      and in the manager itself
      52e12459
    • Marco Trevisan's avatar
      utils: Fix memory leak when error is ignored in list · 554df2a8
      Marco Trevisan authored
      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.
      554df2a8
    • Marco Trevisan's avatar
      device: Fix leaked matched print on identify · 681bd1ed
      Marco Trevisan authored
      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)
      681bd1ed
    • Marco Trevisan's avatar
      device: Don't leak the user on claim error while deleting prints · 88907321
      Marco Trevisan authored
      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.
      88907321
    • Marco Trevisan's avatar
      device: Use g_clear_error instead of doing the same manually · 7dac81dc
      Marco Trevisan authored
      We've now an utility function that can help us to free and unset an error
      double pointer, so let's use it.
      7dac81dc
    • Marco Trevisan's avatar
      delete: Clear the error in case we ignore it · 1ecae1d0
      Marco Trevisan authored
      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.
      1ecae1d0
    • Marco Trevisan's avatar
      device: Always free error in delete enrolled fingers2 · ba7a45d3
      Marco Trevisan authored
      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.
      ba7a45d3
    • Marco Trevisan's avatar
      device: Always free error in delete enrolled fingers · 49dced55
      Marco Trevisan authored
      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.
      49dced55
    • Marco Trevisan's avatar
      manager: Remove unused path variable · e25544a8
      Marco Trevisan authored
      e25544a8
    • Marco Trevisan's avatar
      main: Ensure we always free context, loop and error · ee8589ec
      Marco Trevisan authored
      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.
      ee8589ec
  5. 10 Feb, 2020 2 commits
  6. 07 Feb, 2020 2 commits
  7. 06 Feb, 2020 4 commits
  8. 05 Feb, 2020 11 commits