After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 715119 - MTP Backend can crash during unmount due to overlapping operations
MTP Backend can crash during unmount due to overlapping operations
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: mtp backend
1.18.x
Other Linux
: Normal normal
: ---
Assigned To: Philip Langdale
gvfs-maint
: 719322 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-11-24 17:16 UTC by Philip Langdale
Modified: 2013-12-12 18:54 UTC
See Also:
GNOME target: ---
GNOME version: 3.9/3.10


Attachments
Fail fast during unmounts (7.09 KB, patch)
2013-11-24 17:16 UTC, Philip Langdale
none Details | Review

Description Philip Langdale 2013-11-24 17:16:45 UTC
Created attachment 261360 [details] [review]
Fail fast during unmounts

I've seen a large number of bug reports on Ubuntu (where crash-on-exit is visible due to the crash reporter) related to operations executing during an unmount.
Comment 1 Philip Langdale 2013-11-24 17:31:51 UTC
I recommend taking this fix in the 1.18 branch as these crash-on-exit scenarios seem pretty common.
Comment 2 Ross Lagerwall 2013-11-25 07:36:40 UTC
Wouldn't it be better if this were done at the gvfs daemon level rather than in the backend itself, since I would imagine similar problems occurring with all backends? E.g. the operation should not be forwarded to the backend if an unmount has started.
Comment 3 Ross Lagerwall 2013-11-25 07:38:24 UTC
(In reply to comment #1)
> I recommend taking this fix in the 1.18 branch as these crash-on-exit scenarios
> seem pretty common.

I assume you mean the 1.16 branch?
Comment 4 Philip Langdale 2013-11-25 16:19:59 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > I recommend taking this fix in the 1.18 branch as these crash-on-exit scenarios
> > seem pretty common.
> 
> I assume you mean the 1.16 branch?

Well, master is 1.19 right? So the initial backport would be to 1.18. It's not worth going back to 1.16, me thinks.

There's probably some virtue in dealing with this at the daemon level, yes, but I didn't realise it was a general problem until after I committed the fix and did more poking around.

There's also bug 702385 which is what exposed it in the first place - Nautilus is reliably invoking operations after unmount, which sometimes leads to re-mounting occurring, or an error if the old backend gets the request.
Comment 5 Ross Lagerwall 2013-11-26 06:34:06 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > I recommend taking this fix in the 1.18 branch as these crash-on-exit scenarios
> > > seem pretty common.
> > 
> > I assume you mean the 1.16 branch?
> 
> Well, master is 1.19 right? So the initial backport would be to 1.18. It's not
> worth going back to 1.16, me thinks.

Oh, sorry, I got confused.

> 
> There's probably some virtue in dealing with this at the daemon level, yes, but
> I didn't realise it was a general problem until after I committed the fix and
> did more poking around.
> 
> There's also bug 702385 which is what exposed it in the first place - Nautilus
> is reliably invoking operations after unmount, which sometimes leads to
> re-mounting occurring, or an error if the old backend gets the request.

I opened a new bug to fix this at the daemon level (bug 719327). When that get fixed, we can remove the MTP-specific fix.
Comment 6 Ross Lagerwall 2013-11-30 15:43:34 UTC
This introduced a compilation warning which could possibly cause a crash:
gvfsbackendmtp.c: In function ‘do_query_info’:
gvfsbackendmtp.c:1243:14: warning: ‘elements’ may be used uninitialized in this function [-Wmaybe-uninitialized]

The FAIL_DURING_UNMOUNT(); should be put after all the variable initializers.
Comment 7 Philip Langdale 2013-11-30 18:13:20 UTC
Fixed.
Comment 8 Philip Langdale 2013-12-12 18:54:30 UTC
*** Bug 719322 has been marked as a duplicate of this bug. ***