Description of problem: whenever i export an image, gimp crashes... Version-Release number of selected component (if applicable): gimp.x86_64 2:2.8.0-0.2.RC1.gitff6c280.fc17 @updates-testing How reproducible: always Steps to Reproduce: 1. start gimp 2. open a pnm from scanimage(1) 3. export it Actual results: the image gets exported properly, but: then it crashes: *** glibc detected *** gimp: free(): invalid pointer: 0x00007f431bdbcc63 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x3b21e7c7be)[0x7f431bdb97be] /lib64/libglib-2.0.so.0(g_free+0xf)[0x7f431c14139f] /lib64/libgtk-x11-2.0.so.0(+0x3b30af932f)[0x7f432003432f] /lib64/libgtk-x11-2.0.so.0(+0x3b30ad7d2f)[0x7f4320012d2f] /lib64/libgtk-x11-2.0.so.0(+0x3b30c3ecce)[0x7f4320179cce] /lib64/libgtk-x11-2.0.so.0(+0x3b30c40d9b)[0x7f432017bd9b] /lib64/libgtk-x11-2.0.so.0(+0x3b30c420c9)[0x7f432017d0c9] /usr/lib64/gtk-2.0/modules/libgail.so(+0x386f3)[0x7f43104e76f3] /usr/lib64/gtk-2.0/modules/libgail.so(+0x387f3)[0x7f43104e77f3] /usr/lib64/gtk-2.0/modules/libgail.so(+0x3e8e6)[0x7f43104ed8e6] /lib64/libgobject-2.0.so.0(+0x3b2520f943)[0x7f431c82c943] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x4f8)[0x7f431c844d88] /lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f431c8457c2] /lib64/libgtk-x11-2.0.so.0(gtk_tree_view_remove_column+0x1bc)[0x7f4320197dfc] /lib64/libgtk-x11-2.0.so.0(+0x3b30c62b0f)[0x7f432019db0f] /lib64/libgobject-2.0.so.0(g_closure_invoke+0xd3)[0x7f431c82c5a3] /lib64/libgobject-2.0.so.0(+0x3b252209c5)[0x7f431c83d9c5] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xddd)[0x7f431c84566d] /lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f431c8457c2] /lib64/libgtk-x11-2.0.so.0(+0x3b30b7a70e)[0x7f43200b570e] /lib64/libgobject-2.0.so.0(g_object_run_dispose+0x61)[0x7f431c8326d1] /lib64/libgtk-x11-2.0.so.0(+0x3b30ad86b9)[0x7f43200136b9] /lib64/libgobject-2.0.so.0(g_object_unref+0x1cb)[0x7f431c8315db] /lib64/libgtk-x11-2.0.so.0(gtk_entry_set_completion+0xdb)[0x7f432000ec8b] /lib64/libgtk-x11-2.0.so.0(+0x3b30ad3e07)[0x7f432000ee07] /lib64/libgobject-2.0.so.0(g_object_unref+0x1cb)[0x7f431c8315db] /lib64/libgtk-x11-2.0.so.0(+0x3b30be37c0)[0x7f432011e7c0] /lib64/libgtk-x11-2.0.so.0(+0x3b30ac1e57)[0x7f431fffce57] /lib64/libgobject-2.0.so.0(g_closure_invoke+0xd3)[0x7f431c82c5a3] /lib64/libgobject-2.0.so.0(+0x3b252209c5)[0x7f431c83d9c5] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xddd)[0x7f431c84566d] /lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f431c8457c2] /lib64/libgtk-x11-2.0.so.0(+0x3b30b7a70e)[0x7f43200b570e] /lib64/libgobject-2.0.so.0(g_object_run_dispose+0x61)[0x7f431c8326d1] /lib64/libgtk-x11-2.0.so.0(+0x3b30a86212)[0x7f431ffc1212] /lib64/libgtk-x11-2.0.so.0(+0x3b30ac1e57)[0x7f431fffce57] /lib64/libgobject-2.0.so.0(g_closure_invoke+0xd3)[0x7f431c82c5a3] /lib64/libgobject-2.0.so.0(+0x3b252209c5)[0x7f431c83d9c5] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xddd)[0x7f431c84566d] /lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f431c8457c2] /lib64/libgtk-x11-2.0.so.0(+0x3b30b7a70e)[0x7f43200b570e] /lib64/libgobject-2.0.so.0(g_object_run_dispose+0x61)[0x7f431c8326d1] /lib64/libgtk-x11-2.0.so.0(+0x3b30a86212)[0x7f431ffc1212] /lib64/libgtk-x11-2.0.so.0(+0x3b30ac1e57)[0x7f431fffce57] /lib64/libgobject-2.0.so.0(g_closure_invoke+0xd3)[0x7f431c82c5a3] /lib64/libgobject-2.0.so.0(+0x3b252209c5)[0x7f431c83d9c5] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xddd)[0x7f431c84566d] /lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f431c8457c2] /lib64/libgtk-x11-2.0.so.0(+0x3b30b7a70e)[0x7f43200b570e] /lib64/libgobject-2.0.so.0(g_object_run_dispose+0x61)[0x7f431c8326d1] /lib64/libgtk-x11-2.0.so.0(+0x3b30a86212)[0x7f431ffc1212] /lib64/libgtk-x11-2.0.so.0(+0x3b30ac1e57)[0x7f431fffce57] /lib64/libgobject-2.0.so.0(g_closure_invoke+0xd3)[0x7f431c82c5a3] /lib64/libgobject-2.0.so.0(+0x3b252209c5)[0x7f431c83d9c5] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xddd)[0x7f431c84566d] /lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f431c8457c2] /lib64/libgtk-x11-2.0.so.0(+0x3b30b7a70e)[0x7f43200b570e] /lib64/libgobject-2.0.so.0(g_object_run_dispose+0x61)[0x7f431c8326d1] /lib64/libgtk-x11-2.0.so.0(+0x3b30a86212)[0x7f431ffc1212] /lib64/libgtk-x11-2.0.so.0(+0x3b30ac1e57)[0x7f431fffce57] /lib64/libgobject-2.0.so.0(g_closure_invoke+0xd3)[0x7f431c82c5a3] /lib64/libgobject-2.0.so.0(+0x3b252209c5)[0x7f431c83d9c5] /lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xddd)[0x7f431c84566d] Expected results: it should continue to offer further operations... Additional info: gnumeric and gnome-mplayer produce a core dump whenever i quit...
Hi Arne. I can't reproduce this behavior here. Do you see this crash only when exporting such a scanned PNM image, or regardless of the image (e.g. a background image from /usr/share/backgrounds)? What exactly do you do in the export file dialog?I've seen issues which depend on a "Tab" being pressed at the right spot, so please list every pressed key or keys, and every mouse click. Can you run gimp under a debugger (e.g. gdb) to generate a backtrace?
Hi Nils, yay the bug disappeared... for gnumeric, too... but not gnome-mplayer... i will file an extra bug for gnome-mplayer... bye
I'll assume that something was fixed in glib or gtk meanwhile...
oops... it is back... this should always produce the bug: 0. cd /tmp 1. wget https://secondlife.com/my/_img/promos/upgrade.gif 2. md5sum upgrade.gif (b6f0debb593bb986c96715d28ac8fc55 upgrade.gif) 3. gimp upgrade.gif 4. Export... (upgrade.png) but some other files work fine (most times)... e. g. gimp /usr/share/backgrounds/goddard/default/*/*.jpg (an Export... of the big one to /tmp/bla.png crashed once...)
I can't reproduce this either (fully updated system): nils@gibraltar:/tmp> wget https://secondlife.com/my/_img/promos/upgrade.gif --2012-06-11 16:07:05-- https://secondlife.com/my/_img/promos/upgrade.gif Resolving secondlife.com... 216.82.2.17 Connecting to secondlife.com|216.82.2.17|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 251800 (246K) [image/gif] Saving to: `upgrade.gif' 100%[======================================>] 251,800 421K/s in 0.6s 2012-06-11 16:07:06 (421 KB/s) - `upgrade.gif' saved [251800/251800] nils@gibraltar:/tmp> md5sum upgrade.gif b6f0debb593bb986c96715d28ac8fc55 upgrade.gif nils@gibraltar:/tmp> gimp upgrade.gif Gtk-Message: Failed to load module "pk-gtk-module" GIF: too much input data, ignoring extra... Gtk-Message: Failed to load module "pk-gtk-module" [ exported here, no crash ] Note the "GIF: too much input data, ignoring extra..." line here, it indicates that there is a problem with the original file. Please install the "rpmorphan" package is you don't have it already, run the following command (all in one line) and attach the output file /tmp/gimp-deps.out to this ticket: rpm -q $(rpmdep gimp | sed 's|^gimp depends upon ||g;s|,| |g') | sort > /tmp/gimpdeps.txt Thanks!
Created attachment 591120 [details] requested list of packages that gimp depends on my box is fully updated, too and here (https://bugzilla.gnome.org/show_bug.cgi?id=667012) they describe a similar bug or the same bug... here that 2nd life image export is noisier (and still ends with a core dump): > gimp upgrade.gif GIF: too much input data, ignoring extra... (gimp:28760): GLib-GObject-WARNING **: invalid cast from `GimpDisplayShell' to `GtkWindow' (gimp:28760): Gtk-CRITICAL **: IA__gtk_window_set_transient_for: assertion `parent == NULL || GTK_IS_WINDOW (parent)' failed (gimp:28760): Gtk-CRITICAL **: IA__gtk_tree_model_get: assertion `GTK_IS_TREE_MODEL (tree_model)' failed (script-fu:28770): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Segmentation fault (core dumped) i m using a x86_64 box...
i just installed yum install PackageKit-gtk3-module.x86_64 because it provides libpk-gtk-module.so()(64bit) because: ur box complained about Failed to load module "pk-gtk-module" it seems like i had a bogus "pk-gtk-module" from somewhere... now (after i installed the official one) it works fine... i will test some other exports... :-)
oops if the export file doesnt exist, it still crashes... *sob* but when the "overwrite warning" dialog shows up, there is no crash... but i also got the Gtk-Message: Failed to load module "pk-gtk-module" message now... :-)
I've updated my system so the tree of GIMP's package dependencies is the same as on your system, but still can't reproduce this -- neither exporting to a new, nor an already existing PNG file made it crash. It seems we need to find out how else your setup differs from mine... As I've also tried this with a new user, under both GNOME shell and XFCE, I'd like you to try out if you can do the same and still get GIMP to choke on exporting that file with that new user.
Additionally, can you generate a complete backtrace? To do this, you need to install the debuginfo packages: debuginfo-install gimp Afterwards, run gimp from the command line as follows and attach the output as a file to this ticket: gimp -c --stack-trace-mode=always Thanks!
Created attachment 591396 [details] requested stack trace with debuginfo my box has 4 cores with HT on each... might it be a race condition or so? something about multithreading?
(In reply to comment #11) > Created attachment 591396 [details] > requested stack trace with debuginfo So it is a gtk2 problem... I'll close this as a duplicate of bug #828015, see this one and related bugs for details. > my box has 4 cores with HT on each... Ditto here :-). > might it be a race condition or so? something about multithreading? Maybe, but absolute reproducibility on your side and absolutely none on mine doesn't hint at it. *** This bug has been marked as a duplicate of bug 828015 ***
i deleted my .config/dconf (due to ur hint about using a different account)... then i restored my panel settings... now gimp doesnt crash anymore... :-) thx... bye