573958 - plugin-container ignores LD_LIBRARY_PATH

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Gyorgy Krajcsovits]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

Worked in 3.6.3 that I had my custom built libraries in a directory that was not listed in system wide ldconfig, only in LD_LIBRARY_PATH. In 3.6.4 I got: /local/home/egyokra/opt/firefox/plugin-container: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory.

Workaround is that I've linked the library into the working directory of firefox.

Reproducible: Always

Steps to Reproduce:
1. Put a lib used by some addon-extension into a new directory.
2. Use LD_LIBRARY_PATH to point to directory.
3. Addon should work in 3.6.3 , and not in 3.6.4.
Actual Results:  
See details.

Expected Results:  
No printout, should work as before.

I've got a company managed old Suse 10 desktop where I don't have root rights, so I need to use my user settings for everything.

Comment 1

[Benjamin Smedberg]

http://mxr.mozilla.org/mozilla-central/source/ipc/glue/GeckoChildProcessHost.cpp#200

I'll take a patch which appends instead of overwriting, but it's a low priority so the core devs aren't likely to fix it.

Comment 2

[Gyorgy Krajcsovits]

I don't have the time to prep a build and test it, but I made a small program where I've reproduced this and tested the fix bellow (without the path.get() statement, I just used a string literal). It should be ok, assuming that you meant "append" in the literal sense and did not mean "prepend" :)

After line 50 add inside the ifdef:
#include <stdlib.h>

Instead of
newEnvVars["LD_LIBRARY_PATH"] = path.get();
on line 200, I'd write:
{
    char* tmp = getenv("LD_LIBRARY_PATH");
    std::string ldpath;
    if(0 != tmp) {
        ldpath = tmp;
    }
    if(0 != ldpath.length()) {
        ldpath+=":";
    }
    ldpath+=path.get();
    newEnvVars["LD_LIBRARY_PATH"] = ldpath;
}

Comment 3

[Matthew Turnbull [Bluefang]]

Forgive my ignorance, but why is LD_LIBRARY_PATH being overwritten to begin with?

If I understand the code correctly, it's being set to the location of the plugin-container... but shouldn't that already be in LD_LIBRARY_PATH from the setup done in the run-mozilla.sh script?

Comment 4

[gml4410]

I've hit this problem too.

I'm running FF 3.6.4 on a RedHat4.x system.  Since that has old libraries I've copied more recent ones from another system, dropped them into a special directory and started up Firefox through a script that sets LD_LIBRARY_PATH accordingly.  (I've also patched the binary to use a different dynamic loader, but that doesn't matter here).

Because plugin-container ignores LD_LIBRARY_PATH it now fails to start.

As a result of plugin-container failing to start *Firefox hangs completely*!!!
Surely the whole point of plugin-container is to *reduce* hangs, but it is *causing* them!

Comment 5

[Benjamin Smedberg]

Matthew, most Linux distros use Firefox-on-XULRunner, which doesn't use the run-mozilla.sh script.

Comment 6

[gml4410]

> Matthew, most Linux distros use Firefox-on-XULRunner, which
> doesn't use the run-mozilla.sh script.

Irrelevant.

To be running Firefox you must already be able to access the relevant libraries for plugin-container.

So pass on any LD_LIBRARY_PATH you have.  *Don't* hard-wire it to what may well be wrong (and certainly *is* wrong for a non-zero set of people).

Comment 7

[Benjamin Smedberg]

It is not irrelevant. The standalone glue system used by XULRunner dynamically loads the dependent libraries (libxul etc), so they are not available on the default loader path, and are not (yet) in LD_LIBRARY_PATH.

Comment 8

[gml4410]

Still fails at 3.6.7 (I can't set Version in the details)

Comment 9

[Benjamin Smedberg]

If it were fixed, the bug would say so. Currently nobody is working on this bug.

Comment 10

[gml4410]

A better(?) solution has occurred to me.

This LD_LIBRARY_PATH setting is only there for Linux (it's in an #ifdef OS_LINUX) section.

There is a much better way to get the plugin-container to look in the same directory for its libraries - just set the RUNPATH in the binary to $ORIGIN at link-time.  Then the standard run-time linker will look there regardless of the path to which Firefox was installed. 

(I can't see that the symlink objection expounded in run-mozilla.sh would apply here).

Comment 12

[(not currently active) Ted Mielczarek]

My patch on bug 552864 implements the rpath=$ORIGIN suggestion from comment 10, FWIW.

Comment 13

[Gyorgy Krajcsovits]

Is this going to make it into some future release anyway ? Like I said, I cannot build firefox myself, but if delivery depends on test, I can give it a shot over the next weekend.

Comment 15

[Tanveer Singh]

I am having this problem too. My gcc is in an alternate path, and I cannot use any plugins now. 
So firefox cannot work on any system with libraries in non standard location?

The funny thing is I am having this problem only in firefox 4.0. On firefox 3.6.15, everything is fine

Comment 16

[Tanveer Singh]

This thread seems to be for 3.6.X tree. However, I am able to work with 3.6.17 etc., However, I cannot use firefox 4.0 due to this issue.
My glibc is not in /usr/lib/gcc but in an alternate path. With proper LD_LIBRARY_PATH, firefox can start, but plugin-container crashes, leading to firefox crash.
Is there a fix somewhere which will allow me to use firefox 4.0 instead of 3.6 branch?

Comment 17

[Fernando Herrera]

Any quick workaround for this? I am playing with a plugin for testing AtkPlug/AtkSocket on linux that is only available on GNOME3 stack (that I have installed on /opt/gnome).

Comment 18

[Olaf Flebbe]

I see no point in removing LD_LIBRARY_PATH from the plugins. Iff an admin decides to add shared libs to the runtime path in order to get FF to run, than the plugins will be expected to have the same environment, too.

We use it to get FF 3.6 tun on RHEL4: We se LD_LIBRARY_PATH to inject an gtk2.4 environment and FF works. But flash plugin does not work, because it does not find the supplied gtk environment. In the past we had no problem with it.

Comment 19

[Tanveer Singh]

I do not think this will be fixed as most users have gcc in /usr/lib/gcc
Very rarely you will find old gcc /usr/lib/gcc and users using a newer version of gcc in /usr/somepath/lib/gcc
So its affecting only a small percentage of users, and typically, bugs, which affect only a small percentage of users are very low priority.
So we are sticking to 3.6 now, and cannot migrate to 4.0.

That said I am wondering, for 4.0 tree this same bug will do or do I need to file a new one

Comment 20

[Mike Hommey [:glandium]]

Attachment: Patch

Please test this patch.

Comment 21

[Mike Hommey [:glandium]]

Attachment: Patch

Previous patch is probably not completely safe, though it might work. Please use this one.

Comment 22

[Mike Hommey [:glandium]]

Attachment: Extend LD_LIBRARY_PATH instead of replacing it during plugin-container initialization

Refreshed

Comment 23

[Mike Hommey [:glandium]]

Could those who have the problem test these builds, that include the patch from this bug: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-3d0b32b99e86/

Comment 24

[Mike Hommey [:glandium]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/be89bbf96d54

Comment 25

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/be89bbf96d54