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

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


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