Last Comment Bug 573958 - plugin-container ignores LD_LIBRARY_PATH
: plugin-container ignores LD_LIBRARY_PATH
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: IPC (show other bugs)
: unspecified
: x86 Linux
: -- minor with 3 votes (vote)
: mozilla8
Assigned To: Mike Hommey [:glandium]
:
: [PTO to Dec5] Bill McCloskey (:billm)
Mentors:
: 595795 644484 (view as bug list)
Depends on: 711144
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-23 04:29 PDT by Gyorgy Krajcsovits
Modified: 2011-12-15 10:11 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (1.34 KB, patch)
2011-05-26 04:22 PDT, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Patch (1.34 KB, patch)
2011-05-26 04:25 PDT, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Extend LD_LIBRARY_PATH instead of replacing it during plugin-container initialization (1.73 KB, patch)
2011-06-29 23:06 PDT, Mike Hommey [:glandium]
benjamin: review+
Details | Diff | Splinter Review

Description Gyorgy Krajcsovits 2010-06-23 04:29:04 PDT
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 [:bsmedberg] 2010-06-23 06:16:35 PDT
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 2010-06-23 11:01:50 PDT
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] 2010-06-23 14:30:57 PDT
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 2010-06-24 01:55:00 PDT
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 [:bsmedberg] 2010-06-24 06:14:50 PDT
Matthew, most Linux distros use Firefox-on-XULRunner, which doesn't use the run-mozilla.sh script.
Comment 6 gml4410 2010-06-24 06:18:25 PDT
> 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 [:bsmedberg] 2010-06-24 06:31:37 PDT
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 2010-07-23 10:51:31 PDT
Still fails at 3.6.7 (I can't set Version in the details)
Comment 9 Benjamin Smedberg [:bsmedberg] 2010-07-23 11:52:07 PDT
If it were fixed, the bug would say so. Currently nobody is working on this bug.
Comment 10 gml4410 2010-07-25 17:23:08 PDT
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 11 Josh Matthews [:jdm] (on vacation until Dec 5) 2010-09-13 11:11:16 PDT
*** Bug 595795 has been marked as a duplicate of this bug. ***
Comment 12 Ted Mielczarek [:ted.mielczarek] 2010-09-15 08:35:44 PDT
My patch on bug 552864 implements the rpath=$ORIGIN suggestion from comment 10, FWIW.
Comment 13 Gyorgy Krajcsovits 2010-10-04 00:31:31 PDT
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 14 Benjamin Smedberg [:bsmedberg] 2011-03-25 06:59:53 PDT
*** Bug 644484 has been marked as a duplicate of this bug. ***
Comment 15 Tanveer Singh 2011-03-26 01:23:53 PDT
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 2011-05-04 23:26:58 PDT
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 2011-05-16 02:21:54 PDT
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 2011-05-26 03:17:14 PDT
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 2011-05-26 03:56:27 PDT
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] 2011-05-26 04:22:32 PDT
Created attachment 535299 [details] [diff] [review]
Patch

Please test this patch.
Comment 21 Mike Hommey [:glandium] 2011-05-26 04:25:59 PDT
Created attachment 535300 [details] [diff] [review]
Patch

Previous patch is probably not completely safe, though it might work. Please use this one.
Comment 22 Mike Hommey [:glandium] 2011-06-29 23:06:13 PDT
Created attachment 543068 [details] [diff] [review]
Extend LD_LIBRARY_PATH instead of replacing it during plugin-container initialization

Refreshed
Comment 23 Mike Hommey [:glandium] 2011-06-30 04:34:34 PDT
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/mh@glandium.org-3d0b32b99e86/

Note You need to log in before you can comment on or make changes to this bug.