[PATCH] Fix a SIGSEGV when returning from storage spoke (#983319)

Vratislav Podzimek vpodzime at redhat.com
Mon Aug 26 15:33:35 UTC 2013


On Mon, 2013-08-26 at 10:05 -0400, David Shea wrote:
> On 08/26/2013 09:44 AM, Vratislav Podzimek wrote:
> > On Fri, 2013-08-23 at 17:27 -0400, Chris Lumens wrote:
> >>> This is kinda gross. Backstory:
> >>>
> >>>   - As part of creating a new lightbox (anaconda_lb_show_over), we attach
> >>>     a signal handler (anaconda_lb_move_window_to_parent) to the
> >>>     configure-event signal on the window contained in the lightbox. One
> >>>     of the parameters to this signal handler is the lightbox itself.
> >>>   - Normally this signal handler is called as soon as enlightbox yields
> >>>     to the caller, because that's when the widget is displayed and thus
> >>>     when the first size/position/stacking change occurs. The signals stop
> >>>     when the lightbox is destroyed, because the window can't change
> >>>     anymore.
> >>>   - Except this isn't what happened. When returning from the storage
> >>>     spoke, a new enlightbox dialog was created, and then destroyed, and
> >>>     then the signal handler (that takes the (destroyed) lightbox as a
> >>>     parameter) was called.
> >>>   - Kaboom.
> >>>
> >>> The solution here is to disconnect the signal handler from the window as
> >>> the containing lightbox is destroyed, and also go ahead and emit the
> >>> signal if it never fired in the first place because otherwise the
> >>> stacking is going to be all messed up. This is not a very good solution!
> >>> But hopefully it'll work until we can figure what went wrong with
> >>> setting up the lightbox in the first place.
> >> This looks like a reasonable, kinda gross, not very good solution hack
> >> to me.  Thanks a lot for taking a look.
> > I agree with that. What I see as a proper solution is to make the
> > lightbox more object-oriented -- make it a proper GtkWidget, inherited
> > from the GtkWindow, but having a special attribute for the signal
> > handler ID. Instead of functions creating window and doing a lot of
> > magic, there would be an AnacondaLightbox widget with a constructor
> > taking window to be shown over and doing all the initialization and
> > destruction properly in proper methods.
> >
> I agree. I also think that we should convert it to python. Does the 
> lightbox need to stay in widgets? In its current state, there's no 
> reason for the lightbox to be in libAnacondaWidgets other than that it 
> happens to be in C. I don't think that lightbox as a GtkWidget would be 
> useful in glade interfaces, and having the whole thing in Python would 
> at least make it easier to debug.
Good point!

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list