Meld hangs (waiting for DBus?)

[Cefn]

Recently Meld has started hanging on launch for ten minutes or so before actually appearing.

I don't know what it's hanging on.

On one occasion it reported this after force quitting...
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
...on another occasion it reported...
Failed to register: Timeout was reached
...and never loaded at all.

Sometimes, once a window has launched it is unresponsive (greyed out in Compiz). Sometimes once it has launched, the window is usable, but the next window launched (as part of a workflow like git difftool -t meld -y . ) has the same delay before appearing.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: meld 3.12.0-1
ProcVersionSignature: Ubuntu 3.16.0-34.45-generic 3.16.7-ckt8
Uname: Linux 3.16.0-34-generic i686
ApportVersion: 2.14.7-0ubuntu8.4
Architecture: i386
CurrentDesktop: LXDE
Date: Tue Apr 28 11:39:38 2015
ExecutablePath: /usr/bin/meld
InstallationDate: Installed on 2015-01-01 (116 days ago)
InstallationMedia: Lubuntu 14.10 "Utopic Unicorn" - Release i386 (20141022.1)
InterpreterPath: /usr/bin/python2.7
PackageArchitecture: all
SourcePackage: meld
UpgradeStatus: No upgrade log present (probably fresh install)

[Cefn (6-launchpad-net-cefn-com)]

After a full reboot, Meld behaviour returns to normal...

...until the next time

https://www.youtube.com/watch?v=a1Y73sPHKxw

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Oscar Campbell (ozra)]

Can confirm I've had this for a long time now:

- Meld seems to work fine until I suspend the computer and resume. I'm not two-thousant-percent-sure that is the exact cause, but... Then it gets the DBus hanging problem.

- Sometimes shows diff after half a minute, most times I've aborted because "nothing happens".

- Note, I use meld solely through a small wrapper script in my home-bin, called by git diff: "git-meld" => `meld $2 $5` — but that shouldn't be important for the issue.

[Thomas Kluyver (takluyver)]

I saw something similar, where meld & nautilus were both very slow to start (but then worked normally once they had started). I traced some D-Bus messages with Bustle, and found that there was a request for org.gtk.vfs.Daemon.GetConnection which never got an answer. I guess it waits for a preset timeout and then continues anyway.

The org.gtk.vfs.mountpoint_4098 bus name belonged to a gvfsd-trash process, according to D-Feet. That was managed by a systemd unit called 'gvfs-daemon'. After restarting that, the applications would start quickly again:

    systemctl --user restart gvfs-daemon.service