GNOME Bugzilla – Bug 483502
Save as dialog comes up empty on second use
Last modified: 2018-04-14 23:55:37 UTC
After some lengthy image editing I tried to save an image under a new name, the dialog itself came up but was barren from any dialog elements, only the dialog frame was drawn, the rest of the dialog didn't show up. No related warnings or messages were shown on the console I started the GIMP from :-( Version was SVN as of 2007-09-25.
That's sad, but in order to do something about it we need a way to reproduce this, can you please give us a step by step?
I would like to but no matter how much I tried I can't reproduce this since restarting the GIMP. Retracing my steps involves a selective gaussian blur of radii 130, 200 and then 130 again after canceling the first two about one hour into processing respectively on a large selected area of an image coming straigt from an 8Mp DSLR. Just this part takes the better part of eight hours to reproduce...
Well, there's a risk with working with SVN trunk. You should save way more often then every 8 hours anyway :) I will close this as INCOMPLETE. While we certainly appreciate the time you take to report a bug, the bug report itself is rather useless if it is an obscure error on a random revision without a description of how to reproduce the problem or without a stacktrace. Looking forward to your next bug report.
I would have liked to save earlier, but the processing of the last selective gaussian blur took eight hours!
I updated to yesterdays svn and edited a few images as usual and suddenly the same bug again happened. I failed to reproduce it since but this time I had a console output for the started gimp which spewed "(gimp:5641): Gimp-Tools-CRITICAL **: gimp_draw_tool_draw_boundary: assertion `n_bound_segs > 0' failed" like there was no tomorrow... As I didn't have to go through too many steps I can probably make it happen again, so please let me know how to generate more information to narrow down the problem.
A detailed description on how to reproduce the problem would help a lot. You can also run GIMP in a debugger such as gdb and when the problem occurs, try to get a stack trace and attach it here. It might help to pass the --g-fatal-warnings command-line option to gimp when you are running it in gdb. This will cause gimp to exit immidiately in case of a critical warning. We can then investigate the problem with the resulting stack trace.
Created attachment 96778 [details] 3 layer xcf-file used to reproduce the console warning and strange move tool behaviour.
I tried to reproduce the bug but so far have failed :-( I did get the error message from from gimp_draw_tool_draw_boundary though, so that seems to be unrelated to the bug unless it is responsible or indicative of a memory corruption. There is another strange issue linked with that, let me explain: I have a 3 layer xcf that at one point I load as layers into the current edited image. Sometimes these three layers are not moveable as a whole although they are linked together - if I try to move them directly after loading I can move only the topmost one. I have to then undo that move and have to select either rectangle select or another one of the selection tools to have the GIMP recognize that these three layers belong together again. I just found out how to reproduce this behaviour: Load a JPEG image. In that image load the copyright.xcf as layers. Select the move tool and move the three layers - this should still work. Then load the copyright.xcf again, now try to move that instance of the three layers. The result is the warning from gimp_draw_tool_draw_boundary and only the top layer of the set is moved.
You should have opened a new bug report for this as it doesn't have anything to do with the issue you originally reported.
The warning from gimp_draw_tool_draw_boundary() is fixed now. The behavior of the move tool that you are seeing is expected since you are trying to move the layer mask. Better make sure that the upper layer is selected, not the layer mask in the upper layer.
(In reply to comment #10) > The warning from gimp_draw_tool_draw_boundary() is fixed now. The behavior of > the move tool that you are seeing is expected since you are trying to move the > layer mask. Better make sure that the upper layer is selected, not the layer > mask in the upper layer. > Why then is the behaviour inconsistent? I agree that this is a different bug (I honestly thought those two were related in some way or another) but shouldn't the behaviour be the same no matter how often I load a layer set?
I haven't been able to reproduce that and we shouldn't discuss this here further because it is not relevant for the original problem.
(In reply to comment #12) > I haven't been able to reproduce that and we shouldn't discuss this here > further because it is not relevant for the original problem. > Should I open a new bug for this?
Karl opened bug #484230 for the Move tool issue.
Yesterday, someone in Freenode's #gimp claimed that this happens regularly on the Ubuntu platform. Could it be a theme issue, given that many GTK+ themes out there seem to be somewhat untested?
I also got a report of this today. What is the newest version that this problem showed up with? What's the GTK+ theme?
*** Bug 515846 has been marked as a duplicate of this bug. ***
I've experienced this, and can reproduce it. If I open a .gif file, select an area of it and crop to selection, then save the cropped area using the save as dialog as a second .gif. If I then undo the crop and selection, select a second area, crop to it and then try to use the save as dialog again, the dialog appears without the contents drawn. I have noticed that if I repeat the above steps with an .xcf file as the first file I open, the save dialog coms up ok the second time. I did run gimp from the console, however there weren't any errors reported, and gimp continued to respond even without the save dialog being drawn. I'm running gimp 2.4.5 from apt, under Ubuntu (Hardy Heron) running Gnome, so this bug could well be Ubuntu related, as noted in another comment. As I can reproduce this, are then any other steps I can take to provide more information? I'll also attach gif I was editing when I reporduced the bug.
Created attachment 110717 [details] Gif relating to comment 18
I am pretty sure that this problem is solved by the changes done for bug #528811. But it would probably be too dangerous to backport these changes to the stable branch.
I've had a bug open on this in the Arch linux bug tracker since the start of November last year: http://bugs.archlinux.org/task/8485
Since we have addressed this problem in trunk, it doesn't make sense to keep this any longer on the GIMP product. It is actually a bug in GTK+.
*** Bug 541170 has been marked as a duplicate of this bug. ***
I also have this bug using Ubuntu 8.04 with latest updates. Steps to reproduce : - Open The Gimp - Ctrl-N to open a new image - File > Save : new.xcf - File > Save as : new.png - File > Save as >> bug!
I get the same in Arch linux. I don't know if this will help but this gets dumped onto the command line when the bug happens: (gimp:8480): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error (gimp:8480): Gtk-CRITICAL **: gtk_file_folder_unix_get_info: assertion `strcmp (dirname, folder_unix->filename) == 0' failed (gimp:8480): Gtk-WARNING **: idle activate multiple times without clearing the folder object first. (gimp:8480): Gtk-CRITICAL **: gtk_file_folder_unix_get_info: assertion `strcmp (dirname, folder_unix->filename) == 0' failed I'm running version: GNU Image Manipulation Program version 2.4.6
*** Bug 544504 has been marked as a duplicate of this bug. ***
Hello, I am also seeing this problem, using XFCE4, and GTK theme "MurrinaStormCloud" on Xubuntu 8.04.1 The packages I'm using are: libgtk2.0-0 2.12.9-3ubuntu4 gtk2-engines 1:2.14.3-0ubuntu2 gimp 2.4.5-1ubuntu2 My video card is Nvidia 9800GT, using Nvidia's official driver x86-173.14.12 By the way, I only began using Xubuntu a few weeks ago. I used to use Fedora 9 until then, and Gimp did exhibit the blank "save as" dialog window as well, but it was very rare in that system. In Xubuntu, as soon as I started using Gimp, the second attemt to save a png file gives me a blank "save as" dialog. This does not seem to happen with any PNG file, though. If I edit a 32x32pixel file with 3 layers, as a XCF file, and I save it as XFC, there is no problem. Then I export the file as PNG, and it works (the dialog looks fine). The second time I try to save as PNG, the save as dialog comes up blank. If I open a larger image (some 280x400 pixels), which is a JPG, and add a couple of layers, and save it as XCF, it works (dialogs comes up fine). Then I "save as" PNG, and the "save as" dialog comes up fine. Then, I modify some layer, and try again to save as PNG, and the "save as" dialog comes up correctly again. When the dialog comes up blank, the dialog actually works, though: If I click on the filename area, I can type a file name, and by pressing "Return" on the keyboard the file does get saved. It all works... but the visual components are not there.
*** Bug 551428 has been marked as a duplicate of this bug. ***
Ok, Debian Lenny, KDE (of course ;)) In Lenny this problem began recently. I've read that it's an old scroll bug that already had been resolved so I hope this will be soon resolved again. Solution (patch) : this behavior appears when you chose file type (scroll doesnt work) and let the select open when you click "save", then next time, save dialog opens with this file type select open and crashes. So if you close the select before saving, the bug disappears... NOTA : Every time I see a good app written in gtk (not written in QT!!!) I cry, I realize once more how ilogical this world is : firefox, gimp, inkscape, openoffice,... qt power!!!! (not kde developper, just find it "objectively" better). NOTA : excuse my english, I speak 4 other languages, but here we must speak this. I'm trying to avoid learning this poor and horrible language, I hope one day this world will become a little more logical... NOTA : tired, bad day, hours lost Un saludo
*** Bug 488582 has been marked as a duplicate of this bug. ***
*** Bug 699376 has been marked as a duplicate of this bug. ***
Just noting that bug 699376 contains a simple piece of test code for reproducing this issue.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new