[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