What language are you using GIMP in?

GIMP English version.
Originally I was using GTK+ 2 version 2.6.4
This problem is 'fixed' by rolling GTK+ back to version 2.4.14

I can't reproduce this. What platform was this exactly, btw?

I got the following confirmation by email:


        I use gimp-2.2.4 under Linux 2.4.29 with
a 2-way P5 box and I see similar crashes of
"decompose", which watgrad@gmail.com reported
(Bug 170116: decompose): The Gimp crashes with a
segmentation fault if I decompose a color image
to RGB, HSV, etc., *and* I have a "Histogram"
window open; without a histogram everything
works fine.

Here is the backtrace from the core dump:
    $ gdb -q /site/bin/gimp core
    Core was generated by `/site/bin/gimp'.
    Program terminated with signal 11, Segmentation fault.
    Cannot access memory at address 0x40014d64
    #0  0x08283572 in gimp_histogram_get_maximum (histogram=0xc8ffd70,
channel=269002840) at ../../../app/base/gimphistogram.c:190
    190             max = MAX (max, histogram->values[GIMP_HISTOGRAM_BLUE][x]);
    (gdb)


        After putting a breakpoint right at the
for-loop inside of which the segfault happens
and the running gimp under the control of gdb, I
get the following walkback right before the
application runs into the segfault:
    Breakpoint 1, gimp_histogram_get_maximum (histogram=0xd4b3188,
channel=206840424) at ../../../app/base/gimphistogram.c:186
    186         for (x = 0; x < 256; x++)
    (gdb) bt
    #0  gimp_histogram_get_maximum (histogram=0xd4b3188, channel=206840424) at
../../../app/base/gimphistogram.c:186
    #1  0x0815f5ef in gimp_histogram_view_expose (widget=0x89e0a78,
event=0xbffff2c0) at ../../../app/widgets/gimphistogramview.c:262
    #2  0x4025009e in _gtk_marshal_BOOLEAN__BOXED (closure=0x83c1bd8,
return_value=0xbfffef30, n_param_values=2, param_values=0xbffff090,
invocation_hint=0xbfffef58, marshal_data=0x815f480) at ../../gtk/gtkmarshalers.c:83
    #3  0x405575e9 in g_type_class_meta_marshal (closure=0x83c1bd8,
return_value=0x9fc9601, n_param_values=167548417, param_values=0xbffff090,
invocation_hint=0x9fc9601, marshal_data=0x9fc9601) at ../../gobject/gclosure.c:514
    #4  0x405572eb in IA__g_closure_invoke (closure=0x83c1bd8,
return_value=0x9fc9601, n_param_values=167548417, param_values=0x9fc9601,
invocation_hint=0x9fc9601) at ../../gobject/gclosure.c:437
    #5  0x4056bfcb in signal_emit_unlocked_R (node=0x83c2f48, detail=0,
instance=0x89e0a78, emission_return=0xbffff020, instance_and_params=0xbffff090)
at ../../gobject/gsignal.c:2523
    #6  0x4056d113 in IA__g_signal_emit_valist (instance=0x89e0a78, signal_id=0,
detail=0, var_args=0xbffff220 "(òÿ¿x\n\236\b") at ../../gobject/gsignal.c:2254
    #7  0x4056d6b6 in IA__g_signal_emit (instance=0x9fc9601,
signal_id=167548417, detail=167548417) at ../../gobject/gsignal.c:2288
    #8  0x403424d4 in gtk_widget_event_internal (widget=0x89e0a78,
event=0xbffff2c0) at ../../gtk/gtkwidget.c:3616
    #9  0x4024eb53 in IA__gtk_main_do_event (event=0xbffff2c0) at
../../gtk/gtkmain.c:1342
    #10 0x40435559 in gdk_window_process_updates_internal (window=0x8a8ffc8) at
../../gdk/gdkwindow.c:2182
    #11 0x4043562d in IA__gdk_window_process_all_updates () at
../../gdk/gdkwindow.c:2235
    #12 0x401c19f7 in gtk_container_idle_sizer (data=0x0) at
../../gtk/gtkcontainer.c:1117
    #13 0x405b85d1 in g_idle_dispatch (source=0xc68da30, callback=0,
user_data=0x9fc9601) at ../../glib/gmain.c:3821
    #14 0x405b53d7 in IA__g_main_context_dispatch (context=0x83b0e68) at
../../glib/gmain.c:1947
    #15 0x405b6d8e in g_main_context_iterate (context=0x83b0e68, block=1,
dispatch=1, self=0x83c6b18) at ../../glib/gmain.c:2578
    #16 0x405b70ba in IA__g_main_loop_run (loop=0x9716df8) at
../../glib/gmain.c:2782
    #17 0x0808c0df in app_run (full_prog_name=0x9fc9601
"\200 \rx\200 \rp\230ü\tè\177 \rxå§\b\210\202 \r\020", gimp_argc=1,
gimp_argv=0xbffff6e8, alternate_system_gimprc=0x0, alternate_gimprc=0x0,
session_name=0x9fc9601 "\200 \rx\200 \rp\230ü\tè\177 \rxå§\b\210\202 \r\020",
batch_interpreter=0x9fc9601
"\200 \rx\200 \rp\230ü\tè\177 \rxå§\b\210\202 \r\020", batch_commands=0x9fc9601,
no_interface=0, no_data=167548417, no_fonts=167548417, no_splash=167548417,
be_verbose=0, use_shm=167548417, use_cpu_accel=0, console_messages=167548417,
stack_trace_mode=167548417, pdb_compat_mode=167548417) at ../../app/app_procs.c:375
    #18 0x0808cb5d in main (argc=2, argv=0xbffff6e4) at ../../app/main.c:473


        I put a "return 0.0;" as the first
statement into gimp_histogram_get_maximum() and
the problem disappeared. -- Ok, the histogram did
look dopey then.  ;-)

        The code looked perfectly kosher to me,
so I suspected *histogram containing bad data.
These are two snapshots of *histogram: the first
with probably good data, the second with
possibly rotten data.

Hit breakpoint for the first time --
everything sane:
    (gdb) p *histogram
    $2 = {bins = 177306152,
          values = 0xbcaf9b0,
          n_channels = 197853624,
          mutex = {__m_reserved = 197855680,
                   __m_count = 0,
                   __m_owner = 0x11,
                   __m_kind = 0,
                   __m_lock = {__status = 4,
                               __spinlock = 144804456}},
          num_slots = 17,
          tmp_values = 0x841a3e0,
          tmp_slots = 0x841cd50 "\bS@\b\v\002"}

Hit the breakpoint the last time before the
segfault -- ranty data?
    (gdb) p *histogram
    $3 = {bins = 206838368,
          values = 0xc542268,
          n_channels = 216732360,
          mutex = {__m_reserved = 0,
                   __m_count = 0,
                   __m_owner = 0x49,
                   __m_kind = 16843009,
                   __m_lock = {__status = 16843009,
                               __spinlock = 16843009}},
          num_slots = 16843009,
          tmp_values = 0x1010101,
          tmp_slots = 0x1010101 <Address 0x1010101 out of bounds>}

Can't reproduce with HEAD.  I wonder if this might have been a dup of bug #170570?

After reinstalling GTK+ 2 v 2.6.4 I have not been able to reproduce this problem. 
GIMP 2.2.4  Windows XP SP2

Sorry, I spoke too soon, it is true that the histogram must be set to RGB - then
it does crash.

Ah, that's an important point. Now this is easily reproducable (on GIMP 2.2, the
HEAD branch doesn't have this problem): Open an RGB image, open the Histogram
dialog, set it to RGB, then convert the image to grayscale.

I am pretty sure that this used to work at some point. There is code to handle
the mode change of the image. It does however rely on the behaviour of the
GtkComboBox and this might have undergone subtle changes since this code has
been written.

Fixed in the 2.2 branch, will do a similar change in HEAD:

2005-03-24  Sven Neumann  <sven@gimp.org>

	* app/widgets/gimphistogrameditor.c: change to the Value channel
	if the current channel becomes invalid due to an image mode change.
	Fixes bug #170116.