Closed Bug 1143733 Opened 10 years ago Closed 2 years ago

Firefox should not load libraries from outside app bundle, that conflict with those included in app bundle

Categories

(NSS :: Libraries, defect, P3)

x86
macOS

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: toriningen.me+bugzilla-ruby, Unassigned)

References

Details

Attachments

(8 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150305021524 Steps to reproduce: 1. Create any dummy library 2. Place it into `/usr/local/lib` under the name `libnss3.dylib` 3. Launch Firefox Actual results: Fake `libnss3.dylib` is also present in list of Firefox's loaded modules Expected results: Firefox already has `libnss3.dylib` in it's app bundle directory, so it 1) should not look for alternatives when there is prioritized built-in 2) load multiple instances of library with same name, but different path
Depends on: 1142646
Component: Untriaged → Build Config
Product: Firefox → Core
Can you attach the output of the following commands: - otool -l /path/to/Firefox.app/Contents/MacOS/firefox - DYLD_PRINT_LIBRARIES=1 /path/to/Firefox.app/Contents/MacOS/firefox
Unfortunately I found no way to enable verbose logging for release Firefox, so I'm including dyld log for Nighly for reference. I've replaced long paths with shell-like variables to reduce noise and ease reading, all expansions are included for reference.
The most relevant parts of those logs: [0.034] dyld: loaded: ${RELEASE_APP_BUNDLE}/Contents/MacOS/libnss3.dylib [0.724] dyld: loaded: ${RELEASE_APP_BUNDLE}/Contents/MacOS/libnssckbi.dylib [1.577] dyld: loaded: ${HOMEBREW_PREFIX}/lib/libnss3.dylib nssckbi is (maybe*) dlopening libnss3. It should be given the already loaded one, but for some reason, it's getting the one from homebrew... * considering the time delay between the loading of nssckbi and homebrew's libnss3, it's not entirely clear that it's the case, but it's likely.
Assignee: nobody → nobody
Component: Build Config → Libraries
Product: Core → NSS
Version: 36 Branch → trunk
Attachment #8578663 - Attachment mime type: text/x-log → text/plain
Attachment #8578664 - Attachment mime type: text/x-log → text/plain
Attachment #8578666 - Attachment mime type: text/x-log → text/plain

I was not able to reproduce the bug anymore, checking with both DYLD_PRINT_LIBRARIES=1 and lsof.
Do we have any reason to think we may have fixed the bug somehow?

QA Contact: jjones
Severity: normal → S3
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Priority: -- → P3
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: