Kevin Ryde wrote: >> I wonder how many stack handling bugs like this still hide in our >> PPCODE sections. > > Until I realized the plain CODE: ones should be ok I thought it could be > very scary, what with the gazillion callbacks that can get back to perl > from a gtk func. But if it's only PPCODE then it might be merely a bit > of a pain :-)
I started to go through our code looking for PPCODE sections in modules which also have _ADD_INTERFACES or _ADD_OVERRIDES. So far I've found and hopefully fixed bugs in Gtk2::TreeSortable::get_sort_column_id and Gtk2::CellLayout::get_cells. There might be some more in GtkCellRenderer.xs, GtkWidget.xs, and GtkTreeDnd.xs. But I think this should be it. >> int n_columns = gtk_tree_model_get_n_columns (tree_model); >> + /* extend the stack so it can handle 'n_columns' items in >> + * total. the stack already contains 'items' elements so make >> + * room for 'n_clumns - items' more, move our local stack >> + * pointer forward to the new end, and update the global stack >> + * pointer. this way, xsubs called by gtk_tree_model_get_value >> + * don't overwrite what we put on the stack. */ >> + EXTEND (SP, n_columns - items); > > gtk_tree_model_get_n_columns can callback on a custom model, so I think > an SPAGAIN. Ugh, of course. Committed. Thanks. -Torsten _______________________________________________ gtk-perl-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
