Re: linking / performance / interposing detection ...
On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote: > > So - as part of my -Bdirect work - trying to detect genuine cases of > > interposing - I ran my simple perl script over all my gnome libraries: > > http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome > > specific exclusions file [this incidentally shows lots of other bad > > behavior in Gnome ;-]): > > Very neat. How do interposed symbols happen ? 2 libraries export a symbol with the same name; whomever is dlopened' first (if opened into the global scope) wins & subsequent uses of that name point to the 1st instance. Of course a shared 'free_list' [ cf. the JDK & libcddb ] is most likely not going to work across different implementations ;-) > Is it just people forgetting to put a "static" somewhere? That seems > to be the case for parent_class in metal_gtk2_engine.c. Sure - often that's the case. Ideally every exported symbol should be namespaced - and/or preferably a linker-map used such that ~no symbols but for the gtk_module_init_foo or whatever are exported. Run objdump -T on the library & consider if you really want other people using / conflicting with the result :-) > Yes, we can load any number of theme engines simultaneously. > Fortunately no one cooks gtkrc files that are so fucked up to actually > do this :) I just wonder how clean theme switching is - if you switch from a -> b -> c -> a eg. do we unload them ? > Makes sense. I'm patching gtk-engines right now for the "static"s; it > would be good to file bugs for the other modules which need BIND_LOCAL > changes. Sure - I guess Alex nailed nautilus & gnome-vfs - which both heavily use plugin libs; presumably pango likes modules, I've poked the gstreamer guys separately. Hopefully if you load with BIND_LOCAL you don't introduce eg. libjpeg / libpng etc. into the global symbol search path. HTH, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
Hi Alex, On Tue, 2005-12-13 at 16:31 +0100, Alexander Larsson wrote: > On Fri, 2005-12-09 at 14:36 +, michael meeks wrote: > > I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least > > - > > assuming that does the right thing ) - in all the g_module_opens - > > which would surely be a fairly painless change / patch ? > > I did this for gnome-vfs an nautilus, which i think is the right thing. > Lets see if it causes any trouble. Great; I assume if not we can move onto pango modules, gtk: themes, input methods, pixbuf loaders etc. ? :-) Presumably for any app that loads a diversity of pixbufs - the GdkPixbuf engine would be an obvious target (and completely controlled & contained inside gtk ? ). Thanks anyhow, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
linking / performance / interposing detection ...
Hi guys, So - as part of my -Bdirect work - trying to detect genuine cases of interposing - I ran my simple perl script over all my gnome libraries: http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome specific exclusions file [this incidentally shows lots of other bad behavior in Gnome ;-]): $ find /opt/gnome/lib -name '*.so' | finterpose ./gnome-exlusions I got some rather concerning output wrt. gtk+ theme engines eg. gtk-2.0/2.4.0/engines/libmetal.so exports 'parent_class' Also - the galloping cut/paste common in theme engine authorship seems to have resulted in at least these symbols being duplicated across tons of theme engines: option_menu_get_props is_combo_box find_combo_box_widget get_parent_window reverse_engineer_stepper_box theme_create_rc_style theme_pixbuf_render theme_pixbuf_set_border theme_pixbuf_set_filename theme_pixbuf_set_stretch theme_pixbuf_destroy theme_pixbuf_new theme_pixbuf_get_pixbuf is_combo_box_entry object_is_a combo_box_is_using_list theme_destroy_style theme_realize_style theme_destroy_rc_style theme_unrealize_style theme_set_background theme_parse_rc_style theme_merge_rc_style theme_duplicate_style theme_rc_style_to_style theme_init theme_exit old_vscrollbar_realize old_hscrollbar_slider_update old_vscrollbar_slider_update old_hscrollbar_realize old_hpaned_realize old_vpaned_realize sanitize_parameters is_in_combo_box is_combo is_toolbar_item is_panel_widget_item old_scrolled_window_map old_scrolled_window_size_allocate step_vscrollbar_parent_set So - I guess, this shouldn't be -that- concerning in some ways - but looking further - it *seems* that the loading of themes is done in such a way as to include them in the global symbol search path: gtk/gtkthemes.c: engine->library = g_module_open (engine_path, 0); Q1: is it possible to have 2 gtk themes loaded concurrently ? and if so - why don't we see hideous problems wrt. 'theme_init' being looked up incorrectly in the 2nd theme ? Q2: -why- are we routinely loading all these nice separated plugin libraries into the global symbol search scope ? $ LD_BINDINGS=symbol gtk-demo on my machine shows: 16350: symbol=__gmon_start__; lookup in file=.../gtk-2.0/2.4.0/loaders/libpixbufloader-gif.so 16350: symbol=__gmon_start__; lookup in file=.../gtk-2.0/2.4.0/engines/libindustrial.so 16350: symbol=__gmon_start__; lookup in file=.../pango/1.4.0/modules/pango-basic-fc.so Ok - so they're at the end of the list here it's true - so the effect for gtk-demo is small; but it's easy to imagine loading other libraries, plugins / components etc. after that [ eg. the file-selector + deps ? ;-] and them having to search a number of extra, pointless image loader / pango / theme engine bits per-symbol without any real need for that ? I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least - assuming that does the right thing ) - in all the g_module_opens - which would surely be a fairly painless change / patch ? HTH, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot # glib / gtk modules: g_module_check_init gtk_module_init im_module_init im_module_create im_module_list im_module_exit # gconf gconf_backend_get_vtable # ORBit2 / bonobo orbit_imodule_data Bonobo_Plugin_info # gnome-print gnome_print__transport_get_type gnome_print__filter_get_type gpa_module_init # gnome-vfs vfs_module_init vfs_module_shutdown # glade glade_module_register_widgets # gstreamer gst_plugin_desc # Nautilus nst_init_plugin nautilus_module_shutdown nautilus_module_list_types nautilus_module_initialize # gimp gimp_module_query gimp_module_register # xchat modules xchat_plugin_init xchat_plugin_deinit xchat_plugin_get_info # epiphany register_module # gaim gaim_init_plugin # planner module_init module_exit module_new # a11y modules gnome_accessibility_module_shutdown gnome_accessibility_module_init ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote: > On Fri, 2005-12-09 at 14:36 +, michael meeks wrote: > > > So - as part of my -Bdirect work - trying to detect genuine cases of > > interposing - I ran my simple perl script over all my gnome libraries: > > http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome > > specific exclusions file [this incidentally shows lots of other bad > > behavior in Gnome ;-]): > > Very neat. How do interposed symbols happen? Is it just people > forgetting to put a "static" somewhere? That seems to be the case for > parent_class in metal_gtk2_engine.c. I vaguely recall fixing that in some other theme engine at one point - it was causing crashes when you changed from that theme to another theme and back again, I think. So, yeah, it does cause problems. Cheers, Mark. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
Federico Mena Quintero wrote: >On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote: > > >>Very neat. How do interposed symbols happen? Is it just people >>forgetting to put a "static" somewhere? That seems to be the case for >>parent_class in metal_gtk2_engine.c. >> >> > >Bah, I see now that it is more complicated. The various .c files in the >metal engine do share the parent_class variable - it can't be made >static. > > You should be able to fix it by passing the following arguments to libtool: -export-symbols symbolsfile Where the symbols file contains: g_module_init theme_init theme_exit theme_create_rc_style No other symbols need be exported by the theme engine. James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
On 12/13/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote:> Very neat. How do interposed symbols happen? Is it just people> forgetting to put a "static" somewhere? That seems to be the case for > parent_class in metal_gtk2_engine.c.Bah, I see now that it is more complicated. The various .c files in themetal engine do share the parent_class variable - it can't be madestatic. You can't make it static, but you don't have to export it. G_GNUC_INTERNAL... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
On Tue, 2005-12-13 at 12:26 -0600, Federico Mena Quintero wrote: > On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote: > > Very neat. How do interposed symbols happen? Is it just people > > forgetting to put a "static" somewhere? That seems to be the case for > > parent_class in metal_gtk2_engine.c. > > Bah, I see now that it is more complicated. The various .c files in the > metal engine do share the parent_class variable - it can't be made > static. Then maybe it should have a better name than "parent_class". =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an ungodly devious messiah living undercover at Ringling Bros. Circus. She's a brilliant mutant single mother in the wrong place at the wrong time. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote:
> Very neat. How do interposed symbols happen? Is it just people
> forgetting to put a "static" somewhere? That seems to be the case for
> parent_class in metal_gtk2_engine.c.
Bah, I see now that it is more complicated. The various .c files in the
metal engine do share the parent_class variable - it can't be made
static.
I'm thinking of adding this:
typedef enum
{
G_MODULE_BIND_LAZY = 1 << 0,
G_MODULE_BIND_LOCAL = 1 << 1,
G_MODULE_BIND_MASK = 0x03
+ G_MODULE_BIND_PLUGIN = G_MODULE_BIND_LAZY | G_MODULE_BIND_LOCAL
} GModuleFlags;
and recommending in the docs that people use G_MODULE_BIND_PLUGIN for
"load a plugin" uses of g_module_open().
Thoughts?
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
On Fri, 2005-12-09 at 14:36 +, michael meeks wrote: > So - as part of my -Bdirect work - trying to detect genuine cases of > interposing - I ran my simple perl script over all my gnome libraries: > http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome > specific exclusions file [this incidentally shows lots of other bad > behavior in Gnome ;-]): Very neat. How do interposed symbols happen? Is it just people forgetting to put a "static" somewhere? That seems to be the case for parent_class in metal_gtk2_engine.c. > So - I guess, this shouldn't be -that- concerning in some ways - but > looking further - it *seems* that the loading of themes is done in such > a way as to include them in the global symbol search path: > > gtk/gtkthemes.c: > engine->library = g_module_open (engine_path, 0); > > Q1: is it possible to have 2 gtk themes loaded concurrently ? and if so > - why don't we see hideous problems wrt. 'theme_init' being looked up > incorrectly in the 2nd theme ? Yes, we can load any number of theme engines simultaneously. Fortunately no one cooks gtkrc files that are so fucked up to actually do this :) > Q2: -why- are we routinely loading all these nice separated plugin > libraries into the global symbol search scope ? Ignorance about what each option does, probably :) > I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least - > assuming that does the right thing ) - in all the g_module_opens - which > would surely be a fairly painless change / patch ? Makes sense. I'm patching gtk-engines right now for the "static"s; it would be good to file bugs for the other modules which need BIND_LOCAL changes. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: linking / performance / interposing detection ...
On Fri, 2005-12-09 at 14:36 +, michael meeks wrote: > > I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least > - > assuming that does the right thing ) - in all the g_module_opens - > which > would surely be a fairly painless change / patch ? I did this for gnome-vfs an nautilus, which i think is the right thing. Lets see if it causes any trouble. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a globe-trotting drug-addicted waffle chef with a mysterious suitcase handcuffed to his arm. She's a manipulative African-American widow with only herself to blame. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
