Closed Bug 829604 Opened 11 years ago Closed 11 years ago

Couldn't load XPCOM

Categories

(Core :: XPCOM, defect)

24 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: odoresemprevivo, Unassigned)

Details

Attachments

(2 files)

Attached file strace1
User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

Debian lenny 32bit.
Firefox Requirements: OK!
After upgrading from 17.0.1 to 18.0, i start to receive this error:

XPCOMGlueLoad error for file /tmp/firefox/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Strace: (attached)

Strange because firefox fail to load some local libs.
So running:

LD_LIBRARY_PATH=/tmp/firefox ./firefox
XPCOMGlueLoad error for file /tmp/firefox/libxpcom.so:
/tmp/firefox/libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.
Version: 17 Branch → 18 Branch
Could you please try a Mozilla.org binary build ?
ftp://ftp.mozilla.org/pub/firefox/releases/18.0/
click through platform->language and run the build from /tmp

The undefined symbol error looks like a build issue.
I'm already using a binary build ... i never compiled nothing.
Anyway i downloaded again from ftp://ftp.mozilla.org/pub/firefox/releases/18.0/ but the error still here!
1) I tryed to delete my profile, starting a new one. The problem still here.
2) How can i start firefox in safemode if firefox 18 does not start al all caus stange undefined symbol?
Component: Untriaged → XPCOM
Product: Firefox → Core
Guilius, are you running a 32bit or 64bit OS, and did you download a 32bit or 64bit Firefox binary?
Debian Lenny 5 32bit.
Firefox 18.0 32bit binary downloaded.
I get this same error here on Ubuntu 9.10 64bit, and until now I constantly used binary Firefox distributions from ftp://fto.mozilla.org/pub/firefox/releases with success. Once I've downloaded 18.0 (and 19.0b1 for a test) I get this:

user@computer:/tmp/firefox$ ./firefox
XPCOMGlueLoad error for file /tmp/firefox/libxpcom.so:
/tmp/firefox/libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE
Couldn't load XPCOM.

I used LD_LIBRARY_PATH=/tmp/firefox way as well as setting /etc/ld.so.conf.d way to point system library loader to the right path, but with no success.
Many previous Firefox binary releases, 17.x and some earlier, work fine.
You have exacltly my SAME problem.
Any news?
I got the same error on Seamonkey 2.15.1 (and 2.14.1) (both are 32-bit, directly from Mozilla) after installing 64-bit Linux (Mageia release 2 64-bit) on a new machine.
SM 2.14.1 had worked on my old 32-bit machine (with Mageia release 2 32-bit).

It was fixed by installing 32-bit xulrunner (_not_ the 64-bit version), which pulled in about 20 dependancies.

This seems to be the same problem as bug 704298.
bug 704298 is a different problem than mine.
xulrunner contains same library that firefox had already.
I tryed with 18.0.1, same problem.
Still the same error with latest 19.0 just released (Ubuntu 9.10 64bit). I will attach my strace but as far as I see the problem source is pretty obvious.
Attached file strace
Latest 19.0 run on 64bit Ubuntu 9.10.
OK folks, this bug has had more resurrections than Lazarus.
I have hit it on only a couple of my boxes, and think I know why it is so sporadic.
For one specific case (an EEEPC904 with the original Xandros software) I tried adding FF19 as a tarball:

>/opt/firefox-19.0.2/firefox
XPCOMGlueLoad error for file /opt/firefox-19.0.2/libxpcom.so:
libxul.so: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

But the tarball should contain all the appropriate libs...

> ls -l /opt/firefox-19.0.2/libxpcom.so
-rw-r--r-- 1 root root 11792 2013-03-07 23:22 /opt/firefox-19.0.2/libxpcom.so
> ls -l /opt/firefox-19.0.2/libxul.so
-rwxr-xr-x 1 root root 31031816 2013-03-07 23:22 /opt/firefox-19.0.2/libxul.so
>

Yep, all there.  WTF?

Using strace to look at the startup and sure enough there is the probe for libxpcom.so

lstat64("/opt/firefox-19.0.2/libxpcom.so", {st_mode=S_IFREG|0644, st_size=11792, ...}) = 0

and a little later an open and read

open("/opt/firefox-19.0.2/libxpcom.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\34\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=11792, ...}) = 0
mmap2(NULL, 14616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb78ed000
mmap2(0xb78f0000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb78f0000
close(3)

And here is the killer, a few lines later

open("/lib/i686/cmov/libxul.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/libxul.so", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/lib/libxul.so", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/cmov/libxul.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/libxul.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libxul.so", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/lib/i486-linux-gnu/libxul.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i486-linux-gnu/libxul.so", O_RDONLY) = -1 ENOENT (No such file or directory)
munmap(0xb78de000, 58330)               = 0
munmap(0xb78ed000, 14616)               = 0
write(2, "XPCOMGlueLoad error for file /op"..., 131) = 131


So why is FF looking (unsuccessfully) for libxul.so in the generic places and not in its own secret spot?

I suspect that it may have to do with previously installed xulrunner instances that have left ghosts behind.

BTW, FF17 loads OK, FF18 and 18 die.
I have just reproduced this exact same error in Firefox ESR 17.0.6. Downloaded from:

http://www.mozilla.org/en-US/firefox/organizations/all.html

I used the English (British) release.

I'm running 64bit Ubuntu 13.04.

I added a link to /lib to libxul.so as pointed out by Allan Duncan, and that prevented the error... but then just moved on to complain about libdbus-glib-1.so.2 not existing.
Well, firefox 21.0 has arrived, so I gave it a try on my ancient eeepc, and once again the libxpcom bug raised its head.  This time I made a symlink from the libxul.so in the tarball to libxul.so in the /usr/lib that ff was trying to load, and so it moved on that little bit further to being unable to find libgio.so.

This is paydirt, as it doesn't exit on the eeepc, or in the tarball.  It _does_ exist on my somewhat later desktop where ff-21.0 runs without hiccup.  The package manager (rpm in this case) tells me that libgio belongs to glib2.  Ka-ching!

The eeepc has glib2-2.14.3, the desktop has glib2-2.29.4, so libgio appeared somewhere between those two.  Quoting the info from glib2
   "GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system."

Note the mention of dynamic loading - an area that appears to have gone ugly, as seen in the strace above.

Summary:
If older versions of gnu/linux are to be supported either an older version of glib2 is needed, or a later version that is statically linked maybe?
I tried every binary version from Firefox (18, 19, 20, 21) with the same negative results. I was stuck with Firefox 17.
Finally I read somewhere that this problem was linked to some arcane build trick that could not be fixed easily. So when I saw the announcement of structural changes in Firefox 25 I decided to give a try to the nightly to see if the developers have taken the opportunity to clear this trouble with (somewhat) older Linux libraries. With the same setup (Mandriva 2010) the nightly (24A1) is starting without any problem and is working fine. So I think that this bug will be closed soon.
Cheers.
Closing this as RESOLVED WORKSFORME, based on comment 19. Please reopen the bug if needed.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Well it doesn't work for me.
Same error messages as in comment 18.
I get the libdbus-glib-1.so.2 error when running the Thunderbird 24.0.1 binary in Ubuntu 12.04.3 LTS. I don't seem to be able to change the bug status but if someone could reopen the bug for Branch 24 that would be great thanks!

(The downstream 24.0 and the Daily PPA 27.0a1 (2013-09-22) work fine)
Reopening this based on comment 22.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Version: 18 Branch → 24 Branch
Have you tried setting the LD_LIRBARY_PATH to include the directory where you put the new thunderbird? I had the same libdbus error until I set the path.


#!/bin/bash
DIR_TB=/dir/where/thunderbird/was/untarred
LD_LIBRARY_PATH=$DIR_TB $DIR_TB/thunderbird &


(In reply to adam1eveleigh from comment #22)
> I get the libdbus-glib-1.so.2 error when running the Thunderbird 24.0.1
> binary in Ubuntu 12.04.3 LTS. I don't seem to be able to change the bug
> status but if someone could reopen the bug for Branch 24 that would be great
> thanks!
> 
> (The downstream 24.0 and the Daily PPA 27.0a1 (2013-09-22) work fine)
Could it be that you are on a 64bit OS and trying to run the 32bit version of thunderbird? Download the latest 64bit build from http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/latest/linux-x86_64/en-US/  . The default download on the thunderbird website is the one for i686 and you need to dig in to find the 64bit version.

If you still get those libdbus errors, make sure to install the libdbus-glib-1-2 and libgtk2.0-0.  And if you installed the 386 versions of these, you could run the 32bit version of thunderbird too, if you wanted. (dpkg --add-architecture i386, apt-get install libdbus-glib-1-2:i386 libgtk2.0-0:i386)
Maybe the 64-bit download needs to be more prominent (considering there are so many 64-bit PCs around these days) as well as the Linux package dependencies... but yeah, that fixed it, thanks. If someone could mark it as WORKSFORME again that would be great thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.