Example Gecko library: {"start":2663100416,"end":2713725380,"offset":0,"name":"libxul.so","path":"/mnt/asec/org.mozilla.fennec-2/base.apk!/assets/armeabi-v7a/libxul.so","debugName":"libxul.so","debugPath":"/mnt/asec/org.mozilla.fennec-2/base.apk!/assets/armeabi-v7a/libxul.so","breakpadId":"","arch":""} Example system library: {"start":2756284416,"end":2756321296,"offset":0,"name":"libqservice.so","path":"libqservice.so","debugName":"libqservice.so","debugPath":"libqservice.so","breakpadId":"","arch":""} Looks like the Android part of bug 1329111 wasn't effective.

On Android, we try to get these paths from dl_info->dlpi_name in shared-libraries-linux.cc. My guess is that dlpi_name simple does not contain the full path on Android, and that we get lucky for Firefox libraries because our custom linking magic overwrites dlpi_name with a string that happens to include the full path. glandium, do you know more about this?

(In reply to Markus Stange [:mstange] from comment #1) > My guess is that dlpi_name simply does not > contain the full path on Android So it looks like the linker computes the full path in open_library at https://android.googlesource.com/platform/bionic/+/android-4.2_r1/linker/linker.cpp#607 when it wants to open the file, but it does not store this path in l_name. I suppose we could just reproduce that code on our side - create an ldpaths and an sopaths array, and use sync IO to find the right file. And we could do it either in shared-libraries-linux.cc (preferably after forking it into shared-libraries-android.cc), or we could do it in the linker in __wrap_dl_iterate_phdr when we assign l_name to dlpi_name. What would you prefer?

(In reply to Markus Stange [:mstange] from comment #2) > So it looks like the linker computes the full path in open_library at > https://android.googlesource.com/platform/bionic/+/android-4.2_r1/linker/linker.cpp#607 The version of linker.cpp on android master is actually quite a bit more complicated than that. It doesn't seem to have a hardcoded list of so paths any more, at least not one that I was able to find. With this hardcoded list of search paths, I'm able to assign full paths to all system libraries: "/vendor/lib", "/vendor/lib/egl", "/system/lib", "/system/lib/hw" And then the only library that doesn't have an absolute path is libmozglue.so.

cf. comment in bug 1350500.

I have now updated from Android L to Android M, and I'm getting absolute paths for system libraries even without the patch in this bug. I don't know if it's worth putting more work into the patch until we've found out how many of our testing phones suffer from this problem. The patch I've attached should work for our cases, but it's more of a workaround and I don't know if it's worth landing. It also has the problem that it leaks strings.

Comment on attachment 8862606 [details] Bug 1350501 - Find absolute paths for system libraries on Android. https://reviewboard.mozilla.org/r/134460/#review140426 ::: mozglue/linker/ElfLoader.cpp:107 (Diff revision 1) > +static const char* const sSOPaths[] = { > + "/vendor/lib", > + "/vendor/lib/egl", > + "/system/lib", > + "/system/lib/hw" > +}; If we're going to do this, it shouldn't leak memory, and SystemElf::GetMappable should be adjusted too. ::: mozglue/linker/ElfLoader.cpp:132 (Diff revision 1) > + if (n < 0 || n >= (int)sizeof(buffer)) { > + DEBUG_LOG("Ignoring very long library path: %s/%s\n", path, name); > + continue; > + } > + > + AutoCloseFD fd(open(buffer, O_RDONLY)); access() would be better than open().

Comment on attachment 8862606 [details] Bug 1350501 - Find absolute paths for system libraries on Android. https://reviewboard.mozilla.org/r/134460/#review143372 ::: mozglue/linker/ElfLoader.cpp:128 (Diff revision 2) > + for (size_t i = 0; i < MOZ_ARRAY_LENGTH(sSOPaths); i++) { > + std::string fullPath = sSOPaths[i]; > + fullPath += "/"; > + fullPath += name; > + > + AutoCloseFD fd(access(fullPath.c_str(), O_RDONLY)); access() doesn't return a file descriptor and doesn't take the same arguments as open(). http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html

(In reply to Markus Stange [:mstange] from comment #6) > I have now updated from Android L to Android M, and I'm getting absolute > paths for system libraries even without the patch in this bug. I don't know > if it's worth putting more work into the patch until we've found out how > many of our testing phones suffer from this problem. Our plan mentions Android M as the target for GeckoView, so it seems that we should still fix this bug.

(In reply to Panos Astithas [:past] (please ni?) from comment #10) > (In reply to Markus Stange [:mstange] from comment #6) > > I have now updated from Android L to Android M, and I'm getting absolute > > paths for system libraries even without the patch in this bug. I don't know > > if it's worth putting more work into the patch until we've found out how > > many of our testing phones suffer from this problem. > > Our plan mentions Android M as the target for GeckoView, so it seems that we > should still fix this bug. I actually got this backwards: if Android M doesn't need something like this, then it won't be necessary for GeckoView. The latest profiler fixes give me absolute paths in Android N. Should we wontfix this?

Yes, let's wontfix until we see people run into this problem again.