mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-15 14:25:52 +00:00
6a956c6f97
The current situation looks like this: Firefox launches the plugin-container with two environment variables set: LD_LIBRARY_PATH=$FIREFOX_DIR:$LD_LIBRARY_PATH LD_PRELOAD=$FIREFOX_DIR/libmozgtk2.so:$LD_PRELOAD libxul.so has a dependency on libmozgtk.so (without "2"), but libmozgtk2.so has a SONAME of libmozgtk.so, so ld.so recognizes libmozgtk2.so as a dependency of libxul.so, and uses it instead of the actual libmozgtk.so, making the plugin-container use Gtk+2 instead of Gtk+3 to load Gtk+2 plugins. Now, ASan sets things up in shared libraries such that they needs a symbol from the executable binary. So in the case of plugin-container, the plugin-container executable itself contains some ASan symbols such as __asan_init_v3. libmozgtk2.so, OTOH, contains an undefined weak reference to that symbol, like all other Firefox shared libraries. Since libmozgtk2.so is LD_PRELOADed, it is loaded _before_ the plugin-container executable, and __asan_init_v3 can't be resolved. Disabling ASan for libmozgtk2.so would be a possibility, but the build system doesn't really know how to do that, and filtering out -fsanitize=address can be fragile. The alternative possibility, implemented here, is to change the library loading strategy, renaming libmozgtk2.so to gtk2/libmozgtk.so, and setting the following environment variable when Firefox launches the plugin-container: LD_LIBRARY_PATH=$FIREFOX_DIR/gtk2:$FIREFOX_DIR:$LD_LIBRARY_PATH |
||
|---|---|---|
| .. | ||
| windows | ||
| Makefile.in | ||
| package-manifest.in | ||
| removed-files.in | ||