Last week we’ve been seeing some obscure glib(?) triggered bug. Compile against glib 2.10 and you get something that crashes. To make debugging more fun the crashes are happening only when running on the 770. Compile the same thing against glib 2.8 and it works. The only change in build environment is the glib version, the run environment is exactly the same in both cases, with glib 2.10.
There were some changes to the public headers that might explain the difference in compilation output, but alas reverting the changes that trickle down to compiled code made no difference. The hunt goes on.
Another curious bug is one in gtkcombobox.c which on cursory glance seemed fine, but during debugging proved to produce other than expected results. The line in question is essentially:
maxwidth = MAX (maxwidth, width + (add_padding == 1) ? PADDING : 0);
The idea obviously(?) is to calculate “width + optional padding” but in reality the result is something slightly different. It is left as an exercise to the reader to figure out what is really happening and why 🙂
But fixing that particular bug triggers new bugs elsewhere. GtkComboBox is fairly complicated widget, right up there in the good company of GtkTreeView and GtkMenu. And we’ve been making non-trivial changes to all of them. I can already anticipate how fun it’s going to be to track down the unforeseen consequences of the changes…
View Tommi Komulainen's profile
2 comments ↓
The reason for that bug is operator precedence. That operation is just as:
(width + (add_padding==1)) ? PADDING : 0
just in case width is 0 and (add_padding==1) as well (false), it will be false and therefore 0. But the most of times it will ever be PADDING.
solution: width + ((add_padding==1) ? PADDING : 0)
I’m right or I’m missing something? 🙂
You’re right, that was pretty much it. Adding parentheses would work, though I think the following would be more clear:
if (add_padding)
width += PADDING;
maxwidth = MAX (maxwidth, width);