Bug 607406

Created attachment 426442 [details]
File: backtrace

I see that you are using the QtCurve gtk engine/theme. Meanwhile I've filed an update with the new upstream GIMP version 2.6.9. Please try reproducing your problem with this updated version using both your current and alternatively the default "Clearlooks" theme/gtk engine. The updated gimp packages should hit updates-testing shortly, meanwhile you can grab them here:

https://admin.fedoraproject.org/updates/gimp-2.6.9-1.fc13,xsane-0.997-5.fc13,gegl-0.1.2-3.fc13,babl-0.1.2-4.fc13

Please report back if you can reproduce the problem with either engine.

I have been able to reproduce the crash with gimp-2.6.9-3.fc13.x86_64 (and my current theme QtCurve).
At some point in my editing flow, alt-clicking on a layer mask makes gimp crash. However i don't know an exact sequence that leads to the crash. I haven't tried with Clearlooks yet.

AB.

> However i don't know an exact sequence that leads to the crash.

In fact, if i am lucky enough to save my work (.xcf) just before a alt-click crashes gimp, when i reopen the file with a newly started gimp session, alt-click does work correctly. So gimp must somehow get in a wrong state at some earlier point in my workflow.

AB.

(In reply to comment #4)
> > However i don't know an exact sequence that leads to the crash.
> 
> In fact, if i am lucky enough to save my work (.xcf) just before a alt-click
> crashes gimp, when i reopen the file with a newly started gimp session,
> alt-click does work correctly. So gimp must somehow get in a wrong state at
> some earlier point in my workflow.

I still suspect the QtCurve theme engine to be the culprit here. Have you tried this with the "safe" Clearlooks theme at all?

(In reply to comment #5)
> 
> I still suspect the QtCurve theme engine to be the culprit here. Have you tried
> this with the "safe" Clearlooks theme at all?    

I have worked under Clearlooks for a couple of hours now and i haven't been able to crash gimp.

Changing component accordingly.

I can't see what QtCurve could do to crash gimp while alt-clicking on a mask of a layer in the layerdialog.

I need steps to reproduce it here and the output of: rpm -qa | grep qtcurve

(In reply to comment #8)
> I can't see what QtCurve could do to crash gimp while alt-clicking on a mask of
> a layer in the layerdialog.
> 
> I need steps to reproduce it here and the output of: rpm -qa | grep qtcurve    

Unfortunately, i don't have a step sequence to reproduce the bug. Gimp crashes only when i've been working for a while on an image. If i ever find a sequence, i'll post it for sure.

# rpm -qa | grep qtcurve
qtcurve-gtk2-1.4.1-1.fc13.x86_64
qtcurve-kde4-1.4.3-1.fc13.x86_64
qtcurve-gtk2-1.4.1-1.fc13.i686
qtcurve-kde4-1.4.3-1.fc13.i686

(In reply to comment #8)
> I can't see what QtCurve could do to crash gimp while alt-clicking on a mask of
> a layer in the layerdialog.

The crash happens in the callback function gimp_cell_renderer_viewable_clicked(), here:

...
      if (bevent->type == GDK_BUTTON_PRESS &&
          (bevent->button == 1 || bevent->button == 2))
        {
===>      gimp_view_popup_show (gtk_get_event_widget (event),
                                bevent,
                                cell->renderer->context,
                                cell->renderer->viewable,
                                cell->renderer->width,
                                cell->renderer->height,
                                cell->renderer->dot_for_dot);    <====
        }
...

I'm not very good reading assembler, but my take on the disassembled code in the attached backtrace is that it crashes while dereferencing/accessing cell->renderer->dot_for_dot. Most likely the cell->renderer pointer is invalid which can sensibly only happen after the cell object is finalized (when being deleted), as the renderer member only ever gets set right when the object is created or deleted, never in between.

My wild-assed guess is that using the qtcurve gtk2 engine somehow makes gtk call the gimp_cell_renderer_viewable_clicked() callback _after_ the cell object is unreferenced and (at least partially) garbage-collected. But that's only a shot in the dark.

(In reply to comment #9)
> (In reply to comment #8)
> > I can't see what QtCurve could do to crash gimp while alt-clicking on a mask of
> > a layer in the layerdialog.
> > 
> > I need steps to reproduce it here and the output of: rpm -qa | grep qtcurve    
> 
> Unfortunately, i don't have a step sequence to reproduce the bug. Gimp crashes
> only when i've been working for a while on an image. If i ever find a sequence,
> i'll post it for sure.
> 
> # rpm -qa | grep qtcurve
> qtcurve-gtk2-1.4.1-1.fc13.x86_64
> qtcurve-kde4-1.4.3-1.fc13.x86_64
> qtcurve-gtk2-1.4.1-1.fc13.i686
> qtcurve-kde4-1.4.3-1.fc13.i686    

Is there a reason why you have both arch installed? x86_64 and i686? Does it as well crash when you only have the ones from your base arch installed?

I know meanwhile that gimp can crash if gtk_widget_get_allocation(widget, &alloc)
is used, instead of
alloc=widget->allocation;

But that's not the case here.

(In reply to comment #10)
> (In reply to comment #8)
> > I can't see what QtCurve could do to crash gimp while alt-clicking on a mask of
> > a layer in the layerdialog.
> 
> The crash happens in the callback function
> gimp_cell_renderer_viewable_clicked(), here:
> 
> ...
>       if (bevent->type == GDK_BUTTON_PRESS &&
>           (bevent->button == 1 || bevent->button == 2))
>         {
> ===>      gimp_view_popup_show (gtk_get_event_widget (event),
>                                 bevent,
>                                 cell->renderer->context,
>                                 cell->renderer->viewable,
>                                 cell->renderer->width,
>                                 cell->renderer->height,
>                                 cell->renderer->dot_for_dot);    <====
>         }
> ...
> 
> I'm not very good reading assembler, but my take on the disassembled code in
> the attached backtrace is that it crashes while dereferencing/accessing
> cell->renderer->dot_for_dot. Most likely the cell->renderer pointer is invalid
> which can sensibly only happen after the cell object is finalized (when being
> deleted), as the renderer member only ever gets set right when the object is
> created or deleted, never in between.
> 
> My wild-assed guess is that using the qtcurve gtk2 engine somehow makes gtk
> call the gimp_cell_renderer_viewable_clicked() callback _after_ the cell object
> is unreferenced and (at least partially) garbage-collected. But that's only a
> shot in the dark.    

Sounds like an interesting shot in the dark :) I'm working with upstream on that one. Thanks.

Hey Airbete, could you test it with the latest 1.6.0 in updates-testing. Not sure it's really fixed, but hope so :)

Thanks

qtcurve-gtk2-1.8.1-1.fc14,qtcurve-kde4-1.8.1-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/qtcurve-gtk2-1.8.1-1.fc14,qtcurve-kde4-1.8.1-1.fc14

qtcurve-gtk2-1.8.1-1.fc14, qtcurve-kde4-1.8.1-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update qtcurve-gtk2 qtcurve-kde4'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/qtcurve-gtk2-1.8.1-1.fc14,qtcurve-kde4-1.8.1-1.fc14

qtcurve-gtk2-1.8.1-1.fc14, qtcurve-kde4-1.8.1-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.