tdf#124962: Reduce risk of g_main_loop_run from within gio MountOperation
Using g_main_loop_run here appears to be inherently necessary for the g_file_mount_enclosing_volume/g_file_mount_enclosing_volume_finish protocol, but has at least two problems: For one, it temporarily drops the SolarMutex (if it was held by the current thread), causing the usual integrity issues caused by an inner stack frame temporarily releasing the SolarMutex that is held by some unsuspecting caller. This is an inherent problem of our broken SolarMutex design, and this change can't do much about it. But for another, at least with GTK-based VCL backends, it also means that the current thread can start to execute VCL events at "unexpected" times from within this g_main_loop_run (e.g., paint events, as in the backtraces linked from tdf#124962). While handling of VCL events is necessary when a callback to ooo_mount_operation_ask_password happens and it actually pops up a dialog prompting the user for credentials, such handling of VCL events is completely unwanted when no such dialog is popped up (e.g., when the given server is unreachable anyway, as is the case in tdf#124962). So, to shrink the problematic window of time in which VCL events may get handled from within the gio MountOperation, use a dedicated GMainContext for the gio GMainLoop (so that it only handles events related to the mount operation), and only temporarily put back in place the original GMainContext during ooo_mount_operation_ask_password (so that VCL events will get handled as necessary when a dialog is actually popped up). Change-Id: Ie410f23778045b1adf98579bb34ce38d0f8f3320 Reviewed-on: https://gerrit.libreoffice.org/72026 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Showing
Please
register
or
sign in
to comment