RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Gimp 2.3.1 crash

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.
Gimp 2.3.1 crash Campbell Barton 11 Jun 08:01
  Gimp 2.3.1 crash Sven Neumann 11 Jun 15:53
Gimp 2.3.1 crash David Neary 11 Jun 19:42
  Gimp 2.3.1 crash Nathan Summers 11 Jun 21:01
Campbell Barton
2005-06-11 08:01:52 UTC (almost 19 years ago)

Gimp 2.3.1 crash

Hi, I havnt been able to run gimp since 2.3.1 (2.3.0 worked well - Apart from the useual development bugs)

It always crashes on startup, even if I dont load data. But works if I load the gimp with no UI.
Tried removing all the libgimp libs and my prefs for a fresh install but no good.

GDB Says
Program received signal SIGSEGV, Segmentation fault. 0xb7eecc2b in gimp_param_spec_rgb () from /usr/local/lib/libgimpcolor-2.0.so.0

Heres my output.

____

/gimp-2.3.1 > gimp

(gimp:25314): GLib-GObject-WARNING **: cannot register existing type `GimpConfigInterface'

(gimp:25314): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion `G_TYPE_IS_INTERFACE (interface_type)' failed

(gimp:25314): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `g_type_parent (interface_type) == G_TYPE_INTERFACE' failed

(gimp:25314): GLib-GObject-WARNING **: cannot register existing type `GimpConfigInterface'

(gimp:25314): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion `G_TYPE_IS_INTERFACE (interface_type)' failed

(gimp:25314): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `g_type_parent (interface_type) == G_TYPE_INTERFACE' failed

(gimp:25314): GLib-GObject-WARNING **: cannot register existing type `GimpParamRGB'

(gimp:25314): GLib-GObject-CRITICAL **: g_param_spec_internal: assertion `G_TYPE_IS_PARAM (param_type) && param_type != G_TYPE_PARAM' failed Segmentation fault

Sven Neumann
2005-06-11 15:53:03 UTC (almost 19 years ago)

Gimp 2.3.1 crash

Hi,

Campbell Barton writes:

Hi, I havnt been able to run gimp since 2.3.1 (2.3.0 worked well - Apart from the useual development bugs)

It always crashes on startup, even if I dont load data. But works if I load the gimp with no UI.
Tried removing all the libgimp libs and my prefs for a fresh install but no good.

You are running gimp-2.3 linked against the libraries from gimp-2.2 (or 2.0). Fix your linker setup.

Sven

David Neary
2005-06-11 19:42:50 UTC (almost 19 years ago)

Gimp 2.3.1 crash

Sven Neumann wrote:

Campbell Barton writes:

It always crashes on startup, even if I dont load data. But works if I load the gimp with no UI.
Tried removing all the libgimp libs and my prefs for a fresh install but no good.

You are running gimp-2.3 linked against the libraries from gimp-2.2 (or 2.0). Fix your linker setup.

To elaborate a bit on what Sven has said:

You can tell whether you're linking to the right GIMP libs by running ldd on the gimp-2.3 binary. If you're seeing libs like /usr/local/lib/gimp/2.0/libgimp-2.0.so or /usr/lib/gimp/2.0/libgimp-2.0.so instead of $prefix/lib/gimp/2.0/libgimp-2.0.so then you're linking to the wrong libraries.

This could be because the directory where the older GIMP libraries are installed is in /etc/ld.so.conf - I seem to recall that this plays havoc with link-time linking (which libtool does) and definitely does with runtime linking. I'm not sure what the solution might be if you've installed an official 2.2 or 2.0 GIMP in /usr, and you want to install 2.3.1 in /usr/local or /some/special/prefix - perhaps someone else can give ideas how to get around that problem.

Cheers, Dave.

Nathan Summers
2005-06-11 21:01:35 UTC (almost 19 years ago)

Gimp 2.3.1 crash

On 6/11/05, David Neary wrote:

This could be because the directory where the older GIMP libraries are installed is in /etc/ld.so.conf - I seem to recall that this plays havoc with link-time linking (which libtool does) and definitely does with runtime linking. I'm not sure what the solution might be if you've installed an official 2.2 or 2.0 GIMP in /usr, and you want to install 2.3.1 in /usr/local or /some/special/prefix - perhaps someone else can give ideas how to get around that problem.

the 2.2 libraries can be in /etc/ld.so.conf's path, but the 2.3 cannot be.

$ ldd `which gimp` libgimpwidgets-2.0.so.0 => /usr/lib/libgimpwidgets-2.0.so.0 (0x40030000) libgimpmodule-2.0.so.0 => /usr/lib/libgimpmodule-2.0.so.0 (0x4010e000) etc..

$ ldd `which gimp-2.3`
libgimpwidgets-2.0.so.0 =>
/usr/unstable/lib/libgimpwidgets-2.0.so.0 (0x40018000) libgimpmodule-2.0.so.0 =>
/usr/unstable/lib/libgimpmodule-2.0.so.0 (0x40106000)

where /usr/lib is always in the ldconfig path, and /usr/unstable/lib is most definitely not.

Rockwalrus