GNOME Bugzilla – Bug 329608
Bluefish hangs when saving and closing a project
Last modified: 2006-02-11 04:51:06 UTC
Steps to reproduce: 1 - Create a project in bluefish-unstable 2 - Work on it 3 - Try saving and closing the project Result: Bluefish hangs indefinitely. No crash, so no backtrace. Works fine in bluefish stable.
I cannot confirm it for Debian. Do you get any output when you start bf from the command line?
I should add that this does not happen the first time you create a project, but when you reopen it. I get a warning in the console after clicking the save and close button: the metacity window manager tries to raises a dialog, but metacity-dialog cannot be found in the search binary path.
Is there anything special about the project file? (ie, on a remote server)
No, the project is local, right on my desktop.
> I get a warning in the console after clicking the save and close button: the > metacity window manager tries to raises a dialog, but metacity-dialog cannot be > found in the search binary path. Hmm. Maybe a bug inside the metacity window manager? Normally closing the project will not show a pop-up or a dialog. Can you check, if the metacity-dialog application(?) is installed (if not it's maybe only a dependency problem of metacity wm) or if it is in the PATH variable? Or could you try to make a strace?
The metacity-dialog application is inside the dev part, hence not installed at run time, only at build time. And it is also not in the ordinary bin path, but in prefix/sbin. Anyway, that does not explain why it works with stable version, and not with unstable one.
OK, I've narrowed the problem: 1 - Create a project with two text files in it, just two lines or whatever 2 - Save the project 3 - Reopen the project 4 - Make some change in one file 5 - Save the file (note not the project, but the file) 6 - Save and close the project It floods the console with poll bad file descriptor and you have to kill all daemons, etc... to stop it. Very, very bad. Highly critical to me. Users are not supposed to know how to kill operations. If you operate as follows: 1 - Create a project with two text files in it, just two lines or whatever 2 - Save the project 3 - Reopen the project 4 - Make some change in one file 5 - Omit this step 6 - Save and close the project It works. That's the difference with bluefish stable.
Still unreproducible here (only a bug, that creating a project does not show the project path until you close and reopen the project). Working as described in the first procedure works without a problem here. Can you post the debug output and/or the strace?
Created attachment 58654 [details] Bluefish-unstable gzipped crash log when saving and closing project
The backtrace looks like this is going to be the same cause as the crash you reported in bug #328459
Well, certainly we do not read the same files. I cannot see anything common in those two backtraces, apart the librairies involved. From what I read in the code, it seems that when saving a file from the menu file the editor is redrawn, then when saving and closing the project the editor is also redrawn searching for a reference to the old editor which has already been deleting by the first action. I may be completely wrong of course.
Both backtraces call the exact same functions before crashing. http://bugzilla.gnome.org/show_bug.cgi?id=328459#c3 remove_menuitem_in_list_by_label + 84 (crt.c:355) create_recent_entry + 144 (crt.c:355) add_to_recent_list + 156 (crt.c:355) From comment #9 remove_menuitem_in_list_by_label + 84 (crt.c:355) create_recent_entry + 144 (crt.c:355) add_to_recent_list + 156 (crt.c:355) The backtrace in http://bugzilla.gnome.org/show_bug.cgi?id=328459#c5 is slightly different. This may be a different bug or a related one.
Oh, those, I've compared with the latest one. Well, as as soon as you try to close an item either file or project it tries to close the editor it is relatively normal that it goes through the same steps. Globally, one can say this is the same bug, i.e. a function which does not care enough to what exists or not. It is difficult to say if the second backtrack is related or not as I produce it clicking like a mad on whichever button was available to reproduce the bug. Maybe focusing on the one on project is more reliable, as it is fully reproducible each time.
I thinking this may be locale related because I can't reproduce it yet. Can you recompile with debugging output enabled and run bluefish in a console. I need to see some more debugging messages from Bluefish.
Latest change from cvs solves the bug (change in the order of freeing icon). Closing the bug.