GNOME Bugzilla – Bug 351266
firefox 2.0beta1 crashes when using the browser plugin
Last modified: 2007-04-22 21:40:49 UTC
On Ubuntu edgy, with firefox 2.0beta1 and totem 1.5.91 builds against that version, when trying to use the mozilla plugin firefox crashes with that error: "/usr/lib/firefox/firefox-bin: symbol lookup error: /usr/lib/totem/libtotem-basic-plugin.so: undefined symbol: NS_CStringContainerInit" The crash doesn't happen with epiphany I've tried to change the $(MOZILLA_LIBS) with $(MOZILLA_NOT_LINKED_LIBS) to browser-plugin/Makefile.in _plugin_la_LIBADD and that fixes the crasher downgrading firefox to 1.5 without rebuild totem also fixes the issue
Fair enough. But I'm wondering why did this symbol go away? And what actually uses it.
The firefox ELF executable stopped linking against xpcom, it only links against libxpcom_core.so and libxpcom_compat.so. This missing symbol is in libxpcom.
As this probably is the only missing symbol, we could try and replace whatever is using NS_CStringContainerInit. <hadess> jakub: i'm looking at http://bugzilla.gnome.org/show_bug.cgi?id=351266, and i was wondering whether there was an easy way to see where in the plugin code that function would have been used. any ideas? <jakub> hadess: sure, there is <jakub> hadess: first look in which relocations the symbol is used (readelf -Wr) <jakub> hadess: next step depends on what kind of relocations it is <jakub> hadess: if it is not PLT nor GOT relocation, it is the easiest, just look up the symbol address, find in which symbol (st_value .. st_value+st_size-1) it falls <jakub> hadess: if it is PLT or GOT relocation, it depends on which arch you are looking at, generally search objdump -dr output and see who calls that or who references that <jakub> hadess: or perhaps more easily do that check on the .o files that are linked into the plugin - that way you handle easily even PLT and GOT relocations (as they don't exist in the .o files) <hadess> jakub: whao, excellent <hadess> jakub: thanks
according to ldd -r the undefined symbols are: "undefined symbol: NS_CStringContainerInit (/usr/lib/totem/libtotem-basic-plugin.so) undefined symbol: NS_Alloc (/usr/lib/totem/libtotem-basic-plugin.so) undefined symbol: NS_CStringGetData (/usr/lib/totem/libtotem-basic-plugin.so) undefined symbol: NS_Free (/usr/lib/totem/libtotem-basic-plugin.so) undefined symbol: NS_CStringContainerFinish (/usr/lib/totem/libtotem-basic-plugin.so) undefined symbol: NS_CStringSetData (/usr/lib/totem/libtotem-basic-plugin.so)" they all come from libxpcom.so, firefox 1.5 had "NEEDED libxpcom.so" but that's not the case of the new firefox version
The symbols is used by "nsEmbedCString" in resolve_relative_uri. We can't do without it.
Sebastien, would you mind seeing whether linking against just xpcom would allow for the plugin to carry on working with different versions of the browser?
using "-L/usr/lib/firefox -lxpcom" for the 4 _plugin_la_LIBADD is enough to fix the crasher
(In reply to comment #7) > using "-L/usr/lib/firefox -lxpcom" for the 4 _plugin_la_LIBADD is enough to fix > the crasher But does the plugin still work in the old Firefox and, say, Seamonkey, or Mozilla?
it works with firefox 1.5, mozilla doesn't use the plugin (though it's listed by about:plugins) but it does the same with the unpatched version
What a huge pile of crappety-crap. If I use the plugin in Firefox, but compile it against Mozilla, I get the useful: /usr/lib/firefox-1.5.0.6/firefox-bin: symbol lookup error: /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so: undefined symbol: _ZN8nsMemory5AllocEj when using any Javascript functions. We might just need to link against all the necessary libraries (those given by the CFLAGS), and install only in the subdir for the version we compiled against. That sucks, but I think that's the only way to get it to work properly. Comments? If not, I'll do the changes tonight.
(Side note: I'm not sure a lot of distros are still building against Mozilla, I suppose everybody is moving to Firefox, XULRunner, or SeaMonkey) I received some news from our Firefox maintainers, in Debian bug http://bugs.debian.org/382955, and they said it should be fixed with beta2 in Debian experimental. I'll report back when I have checked, probably tonight.
I confirm it's fixed in Debian, plugin works, ELF deps are: bee% objdump -x /usr/lib/firefox/firefox-bin | grep xpcom NEEDED libxpcom.so NEEDED libxpcom_core.so NEEDED libxpcom_compat.so
Sebastien, how about Ubuntu? If this isn't a problem anymore, I'll close this, leaving my last problem to bug #354490
I workarounded the issue to the totem package for now by building with -lxpcom, if the Debian package of firefox is fixed we will get the fix to Ubuntu soon too probably. I'm fine with closing the bug and considering that as a firefox issue fixed by the new package
*** Bug 402187 has been marked as a duplicate of this bug. ***
Can someone point to the fix for Firefox for this? Is there a Mozilla bug?