Comment 13 for bug 1927100

Revision history for this message
buck2202 (buck2202) wrote (last edit ):

I can tell you anecdotally that I went from pkill-ing gvfsd-trash hourly or worse, to not once since I applied the patch locally in October. But even after all that, I'm not really sure what behavior of mine was triggering the lockup so frequently.

Is an anecdotal user-report like that enough? (obviously using -proposed instead of my local deb repo) FWIW, when committing this change to gvfs, the gnome folks agreed with this comment by their bug's original poster
"I think we should just merge this workaround, it's such an intermittent issue and we know exactly why it happens in glib, and it's low risk. We can't really test it any "better" than merging it and see if the issue ever happens again."

If you'd prefer more, I can rollback from my local deb repo and see if there's any way to passively detect/log the issue (i.e. rather than just noticing it incidentally when a file dialog doesn't appear quickly). I guess the goal there would just be to say the issue occurred X times in Y hours on 1.44.1-1ubuntu1, and zero times in Z hours on -proposed.

I should also note that while the original poster of this bug uses/used Ubuntu Mate 20.04, my own daily driver is actually Mint...so you'd have to judge whether I would be an acceptable tester for this

edit: some googling suggests that 'gio info trash:///' should hang the same way as file dialogs (source: https://forums.linuxmint.com/viewtopic.php?p=1876910&sid=6bb2886d4c755c55a4862eb7add064b9#p1876910). maybe a script that calls that in a loop and logs any time it takes longer than 10s to return would work as a passive test?