Crash on quick exit
Brought to you by:
peter_ono
Menu
▾
▴
#7 Crash on quick exit
Traceback (most recent call last):
File "/usr/bin/gquilt", line 58, in <module>
gquilt.GQuilt(DIR_SPECIFIED).show()
File "/usr/lib/python2.7/dist-packages/gquilt_pkg/gquilt.py", line 174, in init
self._set_playground(os.getcwd())
File "/usr/lib/python2.7/dist-packages/gquilt_pkg/gquilt.py", line 201, in _set_playground
result = ifce.chdir(newpg)
File "/usr/lib/python2.7/dist-packages/gquilt_pkg/ifce.py", line 107, in chdir
ws_event.notify_events(ws_event.CHANGE_WD, newdir)
File "/usr/lib/python2.7/dist-packages/gquilt_pkg/ws_event.py", line 92, in notify_events
del_notification_cb(cb_token)
File "/usr/lib/python2.7/dist-packages/gquilt_pkg/ws_event.py", line 66, in del_notification_cb
index = _NOTIFICATION_CBS.index(cb_token)
ValueError: (1072, <bound method="" mutablepatchtree._repopulate_tree_cb="" of="" \<mutablepatchtree="" object="" at="" 0xf57cbb1c="" (gtkvbox="" 0xa014c18)="">>) is not in list</bound></module>
I get this if I run gquilt in Mozilla repository and close it with the window manager close button before it finishes loading. I can reproduce the problem reliably every time, but it may be trickier to reproduce on a smaller repository. I have two mq patches in the tree.
Lubuntu 14.10 32-bit, gquilt 0.25-3.
Related
Discussion
Anonymous
Sorry for posting the bug anonymously. I could not imagine Sourceforge would allow that.
This will be caused by a race condition on the list.
Just checked the code. I'd taken steps to sidestep this race condition but made an error by assuming the index() returned a value less than zero when the item wasn't present when it actually throws a ValueError exception. Should be an easy fix.
Attached is a patch that should fix this problem. Could you test it please?
I tried the patch with gquilt 0.25. It fails differently.
This appears on the console:
Traceback (most recent call last):
File "/home/proskin/src/gquilt-0.25/gquilt_pkg/gquilt.py", line 180, in _quit
gtk.main_quit()
RuntimeError: called outside of a mainloop
/home/proskin/src/gquilt-0.25/gquilt_pkg/file_tree.py:144: GtkWarning:
IA__gtk_tree_view_expand_row: assertion 'tree_view->priv->model !=
NULL' failed
self.view.expand_row(self.get_path(dir_iter), True)
And this appears in the message box:
Traceback (most recent call last):
File "/home/proskin/src/gquilt-0.25/gquilt", line 58, in <module>
gquilt.GQuilt(DIR_SPECIFIED).show()
File "/home/proskin/src/gquilt-0.25/gquilt_pkg/gquilt.py", line 174,
in init
self._set_playground(os.getcwd())
File "/home/proskin/src/gquilt-0.25/gquilt_pkg/gquilt.py", line 213,
in _set_playground
self.show_busy()
File "/home/proskin/src/gquilt-0.25/gquilt_pkg/gquilt.py", line 184,
in show_busy
self.window.set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH))
AttributeError: 'NoneType' object has no attribute 'set_cursor'</module>
In what context did this occur? E.g. was it while replicating the original bug?
Yes, I was trying to replicate the original bug. I run the patched
gquilt in the Mozilla repository with my local mq patches. If I wait
long enough for my patches to show in the window and then close the
window, gquilt would exit nicely. There are no messages on the console
and no message boxes. If I click on the close button as soon as I see
the window, I get a stacktrace in a message box and another message on
the console. The messages are always the same.
On Tue, Dec 23, 2014 at 9:21 PM, Peter Williams peter_ono@users.sf.net wrote:
--
Regards,
Pavel Roskin
Related
Bugs: #7
I think that this will be very hard to fix without me being able to reproduce it here. Are you happy to keep testing my attempts?
BTW I no longer use gquilt myself. When working with Mercurial and MQ I use my more modern "gwsmhg" GUI which combines Mercurial and MQ management. Have you tried that? For just managing patches, I use my "darning" patch management system instead of "quilt" because it handles renames, permission changes, git binary patches etc. "Darning" has a basic understanding of both git and Mercurial and tries to work with them when used on top of one of their repositories. Have you tried that? Both of these are available on sourceforge.
Meanwhile, I'll try to get at least a work around for your problem.
Also, I've been sitting on a very large set of patches to "gquilt" which bring over a lot of GUI improvements from the other applications (there's a lot of shared concepts). Would you be
I have never heard of gwsmhg. I'll try it. I'm a long time git user
and I have my favorite tools, primarily STGit and tig. I had to
recompile Mozilla Firefox because I need NTLMv2 support now for some
boring work stuff that I would otherwise have to do in Windows (Chrome
supports NTMLv2 but cannot render that page). I fixed a couple of
build system issues in process and used mq to save them. I just needed
a tool to verify mq worked correctly and saved my changes. So I looked
for a hg/mq GUI, and gquilt was the first one I found.
I'd be happy to test further patches it time permits. But I realize
that either I find a tig replacement for hg/mq (not likely) or I
switch to a git mirror of Mozilla.
I've heard of STGit but not tig.
Personally, I have abandoned Mercurial in favour of git and have a (private at the moment) GUI gwsmgitd for managing git repositories (similar paradigm to gwsmhg). I'm reluctant to release it for general use at the moment because paradigms for git management are different to those for hg and I'm still figuring them out so the GUI is incomplete and a bit rough around the edges.
The reason that I make my own GUIs is that none of the existing ones match my way of thinking about managing a project. To me the important things are the files and the state of the working set. This and selecting files from a tree/list for various actions is my main focus. I then add actions to do the most common repository interactions.
My patch management tool (darning) is designed to work on top of git (and hg) repositories and has (to me) the advantage that the patch management does not involve modifications to the repository (so it is never in a state where you can accidentally push patches to a master repository). My intention is to integrate its functionality into gwsmgitd (hence the "d" on the end).
By "work on top", I mean that it knows the state of the files relative to the repository and does things like asking if you wish to incorporate any existing changes in a file into a patch when you add it to a patch. The aim is to also provide a mechanism for incorporate patches into the repository (still under development).
I think our ideas of the workflow are too different. For me, the
purpose of keeping changes in local patches is to make them mature. I
need a tool to review local patches quicky to make sure they are
correct and that they include exactly what I expect. I don't need
another GUI file manager, I'm fine with Midnight Commander (and
increasingly with shell/find/grep). But I want to double-click on a
patch and see what's inside. gquilt and gwsmhg don't have that
functionality unless I'm looking in a wrong place.
One feature I miss in STGit is the ability to push my patches to a
remote repository quickly. Say, I have to leave quickly and I want to
continue working on my patches elsewhere. But all patches should go to
a separate branch, clearly marked as "work in progress".
I like Python and I was a fan of hg when it appeared. But I had to
work with git, I found my favorite tools for git, and it takes too
much effort and frustration to use hg without similar tools.
If you don't want to work on gquilt anymore, it's totally
understandable. If you want me to test some patches, be my guest. I'm
not sure I'll be able to fix gquilt on my own, but I'll have a look if
I have a chance.