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 |
||
|---|---|---|
| .. | ||
| app | ||
| base | ||
| branding | ||
| components | ||
| config | ||
| devtools | ||
| docs | ||
| experiments | ||
| extensions | ||
| fuel | ||
| installer | ||
| locales | ||
| modules | ||
| themes | ||
| app-rules.mk | ||
| app.mozbuild | ||
| build.mk | ||
| confvars.sh | ||
| defs.mk | ||
| LICENSE | ||
| Makefile.in | ||
| moz.build | ||