search

rabbitvcs / rabbitvcs

The new home of rabbitvcs
http://rabbitvcs.org
GNU General Public License v2.0
371 stars 115 forks source link

Rabbitvcs crashes with almost every action on Ubuntu 13.10 #21

Open amraei opened 10 years ago

amraei commented 10 years ago

I'm using Rabbitvcs 0.16.0 for Git on Ubuntu 13.10. I right click and choose an action. It doesn't matter stage, commit, push or etc, a window comes up and freezes most times (90%) after clicking on OK button. Then I have to force close the window and do the job again and again until I find a chance.

Here is a screenshot of frozen window: untitled

It's really terrible to work with Rabbitvcs in this situation. I'm really thinking about getting back to the terminal.

detly commented 10 years ago

We need more information. If you launch one of the GUI commands from the terminal, are there any errors? Are there any errors that look relevant in ~/.xsession-errors? What about in ~/.config/rabbitvcs/RabbitVCS.log?

amraei commented 10 years ago

No, there are no errors when I use terminal. Here are two log files: http://gexek.com/RabbitVCS.log http://gexek.com/RabbitVCS.log.2014-04-08

davidrusu commented 10 years ago

This affects me too, Arch with version 0.16.1

grahambartlett commented 10 years ago

Me too. There is nothing in any RabbitVCS log files, or in xsession-errors. It also is not specific to 13.10 - I've seen this in 14.04 too.

Often I'll close the crashed window, try that operation again, and find that RabbitVCS did actually manage to do the operation. Often it won't have, though. It seems to be more common for the operation to have completed if it is fairly short (e.g. a small commit). If I had to guess, I'd be wondering about whether there's timeouts somewhere. I'm running under VMware, so Ubuntu goes fairly slowly for me (Unity sucks badly in a VM!). I wouldn't be at all surprised to find that this was something that a developer with a native Ubuntu install would never see because they haven't tested under those conditions.

The server doesn't seem to be the problem. We've been happily using this from Windows (via TortoiseGit) and from various Linux terminals. Cola and Giggle work too. So this is very much a RabbitVCS problem.

If it helps narrow down the problem, I do find that RabbitVCS often leaves behind a directory in /tmp. Sometimes these are empty; sometimes they have files in them. It can also crash without creating a directory.

lofidevops commented 10 years ago

If you're under VMware I don't know how easy it is to switch to a TTY? (Ctrl-Alt-F1 to go to TTY 1, Ctrl-Alt-F7 to go back to desktop) Once you're there, run top to confirm that RabbitVCS is in fact consuming lots of resources, or maybe it's Unity (or Unity talking to Rabbit or something else).

FWIW I run native Ubuntu and I do get greyed out RabbitVCS windows occassionally, and also windows hanging around for a bit when the work appears to be complete on a filesystem level - this occurs for me when working on very large SVN repos. Do you get it consistently with particular repos? Perhaps in this case SSHing onto the Ubuntu machine and using the command line is a better option?

grahambartlett commented 10 years ago

Thanks kwill. I've just kicked off a test commit which hung, and gone in with "top". I had three zombie Git processes and a sleeping RabbitVCS (Python) process. I killed the dead commit window, and checked "top" again. The RabbitVCS process had gone, but I still had two zombie Git processes. I've no way of knowing whether these came from RabbitVCS or from Giggle though. (I had a quick go of Giggle, and found it refuses to load any repo at all, and crashes on startup every time. Joy.) I've seen RabbitVCS misbehaving on all our repos. Cola and QGit are solid. So I doubt it's a general problem with Git or the repo.

grahambartlett commented 10 years ago

Correction to my earlier email - I installed Giggle ages back, but I can't remember now whether I actually used it. Enquiring minds might have wondered whether there was some connection with it working then and not now; and my answer would be that I can't remember whether it did work or not! Cola though, I definitely used that when I was getting myself set up, and it's definitely still working.

lofidevops commented 10 years ago

Hmmm, original response asked for ~/.xsession-errors and ~/.config/rabbitvcs/RabbitVCS.log ... do yours also show no errors?

lofidevops commented 10 years ago

(and just to confirm, you are running version 0.16 from the PPA?)

grahambartlett commented 10 years ago

Yes, no errors in either of those files. To be strictly accurate, there's one error from back in April in the RabbitVCS log, from when I typed in a repo URL wrong, but nothing more recent. No errors at all in xsession-errors. I'm using 0.16 from the PPA, in Ubuntu 13.10 with all latest updates. At some point I'll move to 14.04, but we're on a bit of a mission and I don't want the distraction of setting up a new VM and reinstalling everything.

lofidevops commented 10 years ago

At least it's (somewhat) reproducible. It sounds like we need to ask the devs to add more logging (debug package?) to be able to identify where the slowdown is happening. I've seen some recent updates being made to Dulwich recently, so if it is related to something underlying maybe the problem will be resolved whenever 0.16.2 / 0.17 comes out. Here's hoping!