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

David Shea dshea at redhat.com
Mon Aug 26 14:05:22 UTC 2013


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.


More information about the anaconda-patches mailing list