GNOME Bugzilla – Bug 326249
Engines export symbols which might clash with application's symbols
Last modified: 2007-10-07 14:18:47 UTC
Clearlooks engine exports a lot of symbols that have rather very common names (e.g. draw_arrow () etc) that might appear in an application, and in fact, do in ours. ----------- I'm filing this bug also based on the presumption that all the symbols an engine should export are the ones that are needed to initialize the GTypeModule and instantiate the object and create the RcStyle. WRG to the question as discussed on IRC whether the engine or the app should fix their symbol names: An application can't possibly know which symbols an engine has exported, or possibly not even know which engine it's running with, (now not even taking into account it shouldn't export _ANY_ symbols except those stated above); this should be an obvious issue, so it should be clear that it's up to the engine to export only the bare minimum of symbols needed to keep the application safe. Also wrg to the RTLD_LAZY loading issue of theme engines: Actually the engines should be: - Compiled with a .sym file that makes it export only the neccessary symbols - Loaded with the RTLD_NOW flag, which will prohibit it from dangling there and lurking for symbols that it might need at some point (and look up wrong, *possibly*, in the end). Just trying to play it safe. Attached is a patch to the Clearlooks Makefile.am, as well as the .sym file.
Created attachment 56992 [details] [review] Patch to Makefile.am to build with attached .sym file
Created attachment 56993 [details] libtool .sym file for -export-symbols, which exports only the neccesary symbols Clearlooks should export
BTW i filed this as critical because it actually _DID_ make our application crash: Clearlooks tried to look up draw_arrow() in our app instead of finding it's own symbol; please see the statement in the main bug report's body about RTLD_NOW wrg to this.
Interesting, what platform are you using? The draw_arrow symbol you mention is static, so it shouldn't be exported.
The problem is the other way round: Clearlooks was looking for the symbol _in our app_, not the other way round, so no static, G_GNUC_LOCAL (or what it's called) or nothing would have helped. Clearlooks CVS calls this "clearlooks_draw_arrow" now however, and so it's at least _less likely_ this will happen again, but just to pin point my case again: An app can't, in the worst case, not know which theme engine it's being run with, and because of that can't take "countermeasures" or precautions to not have a symbol that clashes with one of the theme's symbols. And again, keep in mind, it was Clearlooks who looked for the symbol in our app. not the other way round, this point is still valid and has nothing to do with the symbols in the theme engine's code being declared static. After putting this together, the best that can be done IMO is to load the theme engines with RTLD_NOW (and _not_ RTLD_LAZY), and to use a .sym file where this is possible. For example, i'm running FC5 Test 2 now, and version of gtk-engines is 2.7.4. For one, check this command's output: [mderezynski@core ~]$ nm -D /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so | grep "^.* T" | wc -l 53 53 exported symbols, where only 5 or so are neccesary (the GTypeModule stuff and possibly, i'm not even sure this is needed, the 2 get_type () functions). And 2ndly, but this is a GTK+ issue, the modules should be loaded with RTLD_NOW.
Sorry guys but i'm tired of your sitting high on a throne chair not even trying to understand the real practical issue attitude, hence i've marked this as INVALID. If you should ever reopen this then you HAVE to, just to not make yourself totally laughable, do something further with it. And please don't try telling me there was no time to look into the matters discussed in the discussion thread attached to this bug. -- M.Derezynski
While clearlooks engine calling a symbol out of the engine is curious and some problem in the toolchain perhaps, it still should certainly not export symbols, like sanitize_size get_direction get_parent_bgcolor and so on and on, into the wild. As Milosz put it, nm -D /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so | grep "^.* T" is pretty enlightening. Reopening to get it (exporting of symbols that it shouldn't export) fixed. We even have a patch proposed.
See http://mail.gnome.org/archives/gnome-themes-list/2006-March/msg00000.html for details.
Ben and I have gone through all exported symbols, in all engines, to make sure nothing gets exported that shouldn't. This should fix the first part of this bug. Most (if not all) internal functions that aren't static are now prefixed, so hopefully this would prevent the library trying to call a function in the application. I assume the only way to be sure is to load the engines with RTLD_NOW ? Moving to general component, as this should not be treated as a clearlooks specific issue.
I am working on both aspects of this. I think we have all engine symbols but the primary 4 now marked internal except that industrial has 2 extra still exported and crux about 5. And, I have been working on prefixing all symbols in all engines (even static) with the engine name etc. Right now I have patch for everything but industrial and crux again, which I am only holding off committing too make sure I don't cause conflicts with Ben's work. We probably also ought to consider using Symbol Versioning under Linux to help prevent future problems there, however since this isn't portable, we still need to ensure namespacing is kept current (and unique enough) with new changes to prevent problems in the future.
All symbols except the needed ones are marked as internal in the engines for quite some time now (which is also tested during "make check"). Does this fix the bug, or is it still possible for the engine to call an application symbol instead of the internal one?
How about simple -export-symbols-regex "g_module_check_init" (or whatever symbol glib picks up in the module)? No need to mark anything as internal/external/whatever, no?
<q>Does this fix the bug, or is it still possible for the engine to call an application symbol instead of the internal one?</q> The original problem was that the engine's symbols were not prefixed (C 'namespaced' :p) with something that would disambiguate them from symbols of an application, (e.g. clearlooks_paint_box, etc); so the problem was twofold, the engine calling into the app (same symbols in the library and the main app -> undefined behaviour), and the app was able to call into the library. Using -export-symbols-regex /clearlooks_.*/ (if that's the right regexp syntax here) should fix the latter problem, and i think the previous one was fixed as well (names are prefixed now).
Well, closing as I think that everything is safe.