After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 51781 - File->Open menu blocked after premature use || segmentation fault
File->Open menu blocked after premature use || segmentation fault
Status: VERIFIED FIXED
Product: GIMP
Classification: Other
Component: General
1.x
Other Linux
: Normal major
: 1.2
Assigned To: GIMP Bugs
Daniel Egger
Depends on:
Blocks:
 
 
Reported: 2001-03-06 18:21 UTC by mroberts
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description mroberts 2001-03-06 18:21:05 UTC
Gimp version 1.1.25

I started the Gimp with a filename:

>gimp filename

While it was loading the picture, I selected
File->Open to select yet another file to open.

(1) If the image pops up while the file dialog is
still open, the dialog disappears, I get a warning
and hitherto the "open" is blocked in the menu.

(2) If I click Ok while the first image is still
loading, it starts loading the second but eventually
halts with a segmentation fault.

The user will have to learn, not to do that. :)
All the best, Mark Roberts
Comment 1 Raphaël Quinet 2001-04-26 18:10:35 UTC
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Comment 2 Raphaël Quinet 2001-08-10 12:40:40 UTC
I just tried this with version 1.2.2.  The bug is still there.

I tried case (1) and indeed the file dialog disappeared.  Afterwards,
the File->Open option in the menu is grayed out (in the toolbox and
in the image windows) and it is not possible to open any file.  The
shortcut (Ctrl-O) is also disabled.  Here are the warnings that are
displayed when the original file appears and the file dialog
disappears:

Gtk-WARNING **: invalid class type `gchar' in cast to `GtkObject'

Gtk-WARNING **: invalid class type `gchar' in cast to `GtkObject'
Comment 3 Daniel Egger 2001-10-24 09:21:11 UTC
Sweet. Thanks Raphael for confirming this, maybe there's a simple
fix for it. I'll have a look.
Comment 4 Sven Neumann 2002-04-12 16:09:09 UTC
Would be nice to get this fixed for 1.2.4.
Comment 5 Sven Neumann 2002-04-12 17:45:22 UTC
Pheww, this one was rather tricky. I've committed a fix for the stable
branch in CVS:

2002-04-12  Sven Neumann  <sven@gimp.org>

 * app/fileops.c: don't set gtk_quit_add_destroy() on fileload and 
 filesave widgets so they don't get destroyed early if the first main
 loop started is a temporary one created for loading images passed on
 the command line. Fixes bug #51781.

 * app/gimpcontext.c (gimp_context_get_standard): same here.

Comment 6 Telsa Gwynne 2002-05-25 16:42:49 UTC
Has there been a release with this fix in yet? Or is it a 
"pull stable from CVS" job currently? 
Comment 7 Raphaël Quinet 2002-05-27 07:04:51 UTC
Currently, you have to get the stable branch from CVS.  As long as a
bug report is in the state "RESOLVED FIXED", this means that the
problem has been fixed in CVS, but not officially released yet.  When
a new version is released, all corresponding bugs are moved to the
state "CLOSED" (I usually try to take care of that in the day
following the official release).
Comment 8 Raphaël Quinet 2003-06-20 16:35:04 UTC
The fix is part of the stable release 1.2.4.  Closing this bug.

Hmmm...  It took me more than "the day following the official relase"
for marking this bug CLOSED.  I hope that Telsa got the files in the
meantime.