GNOME Bugzilla – Bug 729496
Crash with latest gtk+ from master in gtk_combo_box_get_preferred_width
Last modified: 2014-05-05 20:17:30 UTC
Evo from master crashes when initial setup wizard is about to get displayed: Program terminated with signal 11, Segmentation fault.
+ Trace 233548
Thread 1 (Thread 0x7fb62d796980 (LWP 1053))
Probably the crash happens after gtk+ commit: https://git.gnome.org/browse/gtk+/commit/?id=7f60cab47d9651ed3ed53b86f1f74de71b55eee0
This [1] change caused the crash, thus I move this to gtk+. Basically, even if the public API adds always non-NULL parameters, then the descendants doesn't have any good way to call parent class' method through this public API, thus they end with passing whatever they are interested in. It'll be better to revert the change [1]. By the way, evolution's code calls: /* Preferred width of a standard combobox */ GTK_WIDGET_CLASS (e_port_entry_parent_class)-> get_preferred_width (widget, &parent_width_min, NULL); [1] https://git.gnome.org/browse/gtk+/commit/gtk/gtkcombobox.c?id=7455ab72f8681cff908526985f8e4f7ff924aec6
I think the correct way is to pass a dummy variable if you don't care about the result. I'd be happy if you changed that in evolution. I'll add a NULL check in GTK, too, to not make older evolution versions crash.
(In reply to comment #2) > I think the correct way is to pass a dummy variable if you don't care about the > result. I'd be happy if you changed that in evolution. Right, I know it's possible, but the devel doc for gtk_widget_get_preferred_width (and all those other "get_preferred" public API) says it can use NULL for whichever parameter. Of course, it's not the same as calling parent class method, but from my point of view the parent class methods, or basically each implementation of these methods, should follow the devel doc. Changing this in evolution will not fix all 2^10+ applications using gtk in a similar way as evolution does. Thus I do not see any gain in changing evolution itself (I'm sorry). Another (pseudo) reason why not add a dummy variable is that once the compiler, or any static analyser, gets smart enough and will recognize that the variable is not used, will also claim it on console, while I rely on warnings and try to keep the code clean of them - after all, the compiler/static analyser sometimes knows what it says.
The problem is that we don't ever pass NULL to those vfuncs, so if some implementation doesn't check for NULL it will never get noticed until evolution (or the other 2^10 applications) decide to chain up. And we have enough of those widgets that don't handle the NULL case. So I'd like to enforce this as an official stance and say that vfuncs can expect non-NULL arguments for the get_preferred_* functions. After all, everybody passing NULL will notice quickly when their app crashes.