312360 - /home/ianh/firefox/firefox/firefox-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Hixie (not reading bugmail)]

When I update I get:

/home/ianh/firefox/firefox/firefox-bin: error while loading shared libraries:
libmozjs.so: cannot open shared object file: No such file or directory

...after the updater has run.

Comment 1

[Asa Dotzler [:asa]]

Is this just an error or does it prevent the update (or the app) from working?
Could this be a permissions issue related to which user installed the app?

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

I can reproduce this starting provided that I launch Firefox from a different
directory than it is unpacked to, eg ~/test/firefox/firefox -P, rather than
[~/test/firefox] ./firefox -P

The update still applies ok (doesn't fall back from partial to complete update,
buildID incremented from 2005101204 to 2005101304), but the application fails to
relaunch afterwards. Calling ~/test/firefox/firefox again launches the browser
without problems.

CC'ing startup-foo-master bsmedberg

Comment 3

[Benjamin Smedberg]

Darin, can you think of a reason why the LD_LIBRARY_PATH would be wrong after
updating?

Comment 4

[Darin Fisher]

No, I can't imagine how that could happen, but it must be happening.

Comment 5

[Darin Fisher]

bsmedberg: actually, i suspect it must be the case that LD_LIBRARY_PATH includes
a relative path instead of an absolute path.  when applying the update, we chdir
into the firefox application directory, and then we spawn the updater, which
spawns firefox again into the application directory.  at that point, the current
directory is no longer what it was when "firefox" the shell script ran.  so, my
guess is that we must not be setting an absolute path in LD_LIBRARY_PATH.

Comment 6

[Asa Dotzler [:asa]]

Not going to block on this. Ben, if you can come up with something here, let us
know and we'll evaluate a patch but this isn't high impact enough -- it's my
understanding that next time you run the update works so there's a simple
workaround.

Comment 7

[Scott MacGregor]

Jay ran into this today too. 

Comment 8

[Darin Fisher]

Ian and I looked into this a bit today, and it turns out that my hunch was
correct.  The problem is that LD_LIBRARY_PATH contains a relative file path.  I
suspect that the best solution here is to pass the original working directory to
updater on the command line and have the updater chdir back to the original
working directory before launching firefox.

Comment 9

[Scott MacGregor]

Benjamin, any chance you could keep poking at this over the next day or so?
Darin already has a lot on his plate. As Asa said, we'd still be interested in
evaulating a fix for this.

Comment 10

[Jay Patel [:jay]]

If we can come up with a quick, low-risk patch for this, I would like to see
this get into RC1.  Definitely not high impact for all of our users (if we count
Windows), but I think for Linux users, this is going to affect most of them. 
From what I understand, this is a problem if you are trying to run the app from
any dir other than the install dir...which many Linux users do all the time.

So if we want to keep our Linux users happy, this is one of those really
annoying bugs that we should get fixed if we want to keep a positive light on
Software Update... what's the point of making a huge deal of it if you can't
seemlessly update a build and expect it to startup after the update is applied?!

Darin/Benjamin: Please submit a patch so we can renominate this and get it in.

Comment 11

[Chase Phillips]

Jay accidentally set blocking1.8rc1?.  Setting it back to blocking1.8rc1- on his
behalf.

Comment 12

[Darin Fisher]

I have a patch for this.

Comment 13

[Darin Fisher]

Attachment: v1 patch

This implements the solution from comment #8.

Comment 14

[Benjamin Smedberg]

Comment on attachment 200291 [details] [diff] [review]
v1 patch

Eesh... perhaps (not now) we should think about whether we should pass a
directory to updater instead of changing directory there in the first place.

Comment 15

[Darin Fisher]

> Eesh... perhaps (not now) we should think about whether we should pass a
> directory to updater instead of changing directory there in the first place.

Yeah, moving all of the chdir business into updater would be a lot cleaner.

Comment 16

[Darin Fisher]

fixed-on-trunk

Comment 17

[Darin Fisher]

fixed1.8

Comment 18

[Chase Phillips]

Could the patch in this bug have caused bug 313623?

Comment 19

[Darin Fisher]

I don't see an obvious connection other than the check-in times. I'll investigate to see what I can come up with.