Open Bug 1373859 Opened 5 years ago Updated 5 years ago

gdb needs to set LD_LIBRARY_PATH for its target rather than mach setting it for gdb

Categories

(Core :: XPConnect, defect, P3)

defect

Tracking

()

People

(Reporter: keeler, Unassigned)

References

(Blocks 1 open bug)

Details

My understanding is the common way to tell gdb where to find shared library files for its target is to set LD_LIBRARY_PATH in gdb's environment. As far as I can tell, that's what's happening when running e.g. `./mach xpcshell-test --debugger=gdb path/to/test.js` (and I imagine most of our tests under a debugger). However, it turns out this can cause problems. For example, if you build with TSan enabled (ac_add_options --enable-thread-sanitizer - see bug 929478), commands like the agove will fail with:

/usr/bin/gdb: symbol lookup error: /home/keeler/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/bin/libnspr4.so: undefined symbol: __tsan_init

What appears to be happening here is that gdb needs to load libnspr4.so (before it even loads up xpcshell). Because LD_LIBRARY_PATH has been set by mach, gdb looks in that path for the library. Lo and behold, it's there (because we build a copy ourselves). However, since TSan has been enabled, that shared library depends on the symbol __tsan_init (and others), which is actually defined in xpcshell (and firefox, and other binaries). However, since xpcshell hasn't been loaded yet, that symbol isn't defined and loading fails.

gdb's documentation would seem to indicate that the right thing to do is to `set solib-search-path` or similar, but I couldn't get this to work, even in non-TSan examples. It's possible this is just broken in gdb.

What I did get to work was to run `set environment LD_LIBRARY_PATH <the path>` in gdb, so we should change mach to do that if possible.
So the problem is that gdb itself depends on libnspr4, and because of LD_LIBRARY_PATH, it ends up picking the one from the build, which, when building with tsan, doesn't work in that context.

Seems to me we should add a rpath to xpcshell or switch it to the standalone glue, and stop setting LD_LIBRARY_PATH completely.

Which makes this a xpcshell bug more than build config. (although that might be fixed by build system changes) Then there's also a part that belongs to the xpcshell test harness.

Note, the firefox binary can be used as a bootstrap for xpcshell nowadays (although ISTR there's an open bug about it not working entirely on some platform), maybe we could kill xpcshell at some point?
Component: Build Config → XPConnect
(In reply to Mike Hommey [:glandium] from comment #1)
> So the problem is that gdb itself depends on libnspr4

What in the world is GDB depending on libnspr4 for?  I cannot imagine this being true.
(In reply to Nathan Froyd [:froydnj] from comment #2)
> (In reply to Mike Hommey [:glandium] from comment #1)
> > So the problem is that gdb itself depends on libnspr4
> 
> What in the world is GDB depending on libnspr4 for?  I cannot imagine this
> being true.

Fedora has everything use nss for crypto, I bet some system library depends on nss, which depends on nspr. I see no other reason for gdb to be loading nspr before xpcshell.
BuildConfig seems a better component fit. Please feel free to reset the module if I got something wrong.
Component: XPConnect → Build Config
See comment 1.
Component: Build Config → XPConnect
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.