Re: [Re: [Re: [[gtkmm] Glib::RefPtr also for Widgets?] ] ]



>I don't know. My point is that I'm only interested in gtkmm2 test cases, and I
>would quite like too see such a bug report for gtkmm2 because we might be able
>to fix the problem if it exists. It's easier to deal with real test cases than
>theory.

actually, if you don't mind, i'll use theory to let you know that
gtkmm cannot solve this. if gtk+2 doesn't take an extra reference to
the widget in question when signal emission starts, then for any
button_press event, "delete this" from the handler will theoretically
cause a segfault. you may never see it, because of the way your
program uses memory, but its technically a coding error to do
this. the widget's lifetime needs to extend to the next button_release
event for almost all widgets.

gtkmm can't fix it because the reference has to be taken *before*
signal emission begins. if gtkmm tried to fix it, it would be doing it
from a proxy handler, and thus deletion would still occur once control
returned to the proxy, before it hands back to the GTK+ code that
expects the widget to still exist.

however, it is possible that this was fixed in gtk+2 by taking the
extra reference and removing it at the end of signal handling.

the exact same behaviour occurs for a pure GTK+ program that calls
gtk_widget_delete() from a signal handler, so its hardly a "bug" in
gtkmm.

--p



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]