GNOME Bugzilla – Bug 697143
Meld hangs and sets the wrong pid in window properties
Last modified: 2013-05-24 22:19:16 UTC
I am on FreeBSD 9.1. Sometimes, when I click "Close" button on the window, meld hangs. Kde4 window manager reads pid from the window properties, but pid there is invalid, see by original kde4 PR: https://bugs.kde.org/show_bug.cgi?id=317750 As a result, kde4 is unable to kill this hanged process with its default workflow. So one issue is that meld sets the wrong pid for the window, possibly during fork. Another issue is that it hangs when "Close" button of the window is clicked. This doesn't happen every time, but happens now and then regularly.
We don't set pids anywhere, and we don't fork/exit. We *do* use Python's multiprocessing, and while I'd definitely that this is the issue, I'm not sure what to do about it. Regarding both issues, could you please test the current git version of Meld? A few multiprocessing fixes went in after 1.7.1 was released, and I'd like to know whether they fix things before spending any more time on this. Also, when you get the hang, is there any traceback information on the terminal?
I am not as familiar with python. So this is probably python issue. I will file it with python itself. Will use git version for now to test. Thanks! Yuri
Here is the python PR for this issue: http://bugs.python.org/issue17622
I didn't say that this was a Python bug. It's more likely that it's a problem with our *use* of multiprocessing, or possibly the integration between that and the GTK mainloop. Having said this, I can't reproduce this problem at all on linux. With current HEAD, 1.7.1 and 1.7.0 this all works fine, and the PIDs set on the window properties are correct. It seems unlikely to me that this is something we're doing. As far as the hang goes, I'd like to know whether that still occurs in head, and whether it is related to our multiprocessing use. You could also try forcing Meld to run with threads by changing CachedSequenceMatcher.__init__ to always use a ThreadPool rather than a Pool, as we do on Windows, though really that would just be a workaround.
I am using 1.7.1. Might be an issue specific for FreeBSD or *BSD. And it happens once in a while for a long time. Wouldn't this happen when process forks, and the child takes charge of an X-connection, and parent dies later without reassigning window property? One way to make situation more transparent is to set the process titles for every process. setproctitle(3) So that every time you fork, child will have some meaningful title appearing on ps output. This way we at least could tell what the processes under 'python' name really do. Also you can add debug printout: "process started (pid=NNN) for task_blah_blah" "process ended (pid=NNN) for task_blah_blah" This will make situation more clear. Currently, I get this printout, which doesn't seem useful for anything: Couldn't bind the translation domain. Some translations won't work. ** (process:63010): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (process:63010): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (process:63010): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' /usr/local/lib/meld/meld/meldwindow.py:580: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed self.notebook.append_page(page.widget, nbl)
(In reply to comment #5) > I am using 1.7.1. Might be an issue specific for FreeBSD or *BSD. And it > happens once in a while for a long time. As I said, some multiprocessing related fixes went in *after* 1.7.1 was released, so without testing with those I don't know whether this is fixed already. > Wouldn't this happen when process forks, and the child takes charge of an > X-connection, and parent dies later without reassigning window property? There's no reason for the child processes to touch anything X-related. In 1.7.1 I can see that that could *possibly* happen unintentionally (though it would be weird), but I can't see how it would happen in current git at all. > One way to make situation more transparent is to set the process titles for > every process. setproctitle(3) So that every time you fork, child will have > some meaningful title appearing on ps output. This way we at least could tell > what the processes under 'python' name really do. > > Also you can add debug printout: > "process started (pid=NNN) for task_blah_blah" > "process ended (pid=NNN) for task_blah_blah" > This will make situation more clear. Fair enough, but I know exactly what the processes do. They're helpers for parallelising our inline diff comparisons. > Currently, I get this printout, which doesn't seem useful for anything: <snip> None of this is relevant to the current situation. I don't know why you're getting those earlier messages; I assume BSD-specific issues, but either way that's not Meld. The last one is a known problem, but with little-to-no effect.
I just reproduced the issue with today's git snapshot. It hanged and wrong pid was in window props.
Have you tried the possible fix I mentioned? Specifically, in filediff.py around line 65, replace: if self.process_pool is None: if os.name == "nt": CachedSequenceMatcher.process_pool = ThreadPool(None) else: # maxtasksperchild is new in Python 2.7; this is for 2.6 compat try: CachedSequenceMatcher.process_pool = Pool( None, matchers.init_worker, maxtasksperchild=1) except TypeError: CachedSequenceMatcher.process_pool = Pool( None, matchers.init_worker) with: CachedSequenceMatcher.process_pool = ThreadPool(None)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!