MTP: Use improved libmtp event polling mechanism to fix unmount race

Welcome to the end of this little road.

With all the refactoring in place, we are now in a position to
introduce the use of LIBMTP_Read_Event_Async. This version of
Read_Event uses an explicit asynchronous API, which gives us more
control over how long it blocks in a polling call, and what happens
if it is interrupted.

According to libusb documentation, a blocking poll will be interrupted
when the device being polled is closed. This means we should be
able to block indefinitely, and close the device during our
unmount and have the poll call return so our thread can terminate
cleanly.

In theory, this approach should work with the original poll
mechanism using the synchronous API, but that seems risky based
on the crashes we've seen. When the synchronous API is interrupted,
it returns to code (in libusb) that doesn't actually stop polling;
it will attempt to start the poll operation again. This leads to
a segfault as the device state is gone.

By using the explicit asynchronous API, we are able to ensure
that only safe code is called after the interruption.

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=761278

1 files changed, 5 insertions, 0 deletions

diff --git a/configure.ac b/configure.ac
index 7adcb7de..2d3ca0e0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -545,6 +545,11 @@ if test "x$enable_libmtp" != "xno" -a "x$msg_gudev" = "xyes"; then
         [AC_DEFINE([HAVE_LIBMTP_1_1_9], 1, [Define to 1 if libmtp 1.1.9 is available])],
         []
     )
+
+    PKG_CHECK_MODULES(LIBMTP_1_1_12, libmtp >= 1.1.12,
+        AC_DEFINE(HAVE_LIBMTP_1_1_12, 1, [Define to 1 if libmtp 1.1.12 is available]),
+        []
+    )
   fi
 fi