[SR-5414] ImageInspectionELF.cpp:getSectionInfo crashes on Android

[johnno1962]

Previous ID	SR-5414
Radar	None
Original Reporter	@johnno1962
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug, Android, Runtime
Assignee	None
Priority	Medium

md5: eeaeadc9273523842bc94cdc82be6101

relates to:

• SR-5438 Something is up with do/try/catch on the port to Android

Issue Description:

Due to dladdr() not returning the full path to an executable upstream when swift is running on Android calls to getSectionInfo() in stdlib/public/runtime/ImageInspectionELF.cpp fail when it tries to perform a dlopen(imageName, RTLD_LAZY | RTLD_NOLOAD). This description is out of date - see below.

[johnno1962]

PR #10836 created to workaround this for now

[johnno1962]

I’ve spent a bit more time investigating this wondering if it might be connected to the only other known problem with Swift on Android https://bugs.swift.org/browse/SR-5438.

After inserting logging I can see this code is succuessfully dlopen()ing the dynamic libraries of the app even though it is not providing the full path with the exception of one, in my case “dll”, “net.zhuoweizhang.swifthello” which must be the main application. The PR mentioned above is correct in that it makes failure to dlopen in getSectionInfo a non-fatal error on Android due to this outlier.

As the sections are being opened and located there is no reason to believe that whatever this code does isn’t working.

[gonzalolarralde]

The reason why this is required for bionic is because `dl_iterate_phdr` is not only returning the currently opened libraries, but also the executable file. When the iterator reaches the executable file path, `RTLD_NOLOAD` avoid loading it at all, so the return value for that call is `null`.

This is what glibc's `dl_iterate_phdr` would return for `exec_test`:

1: `null` < will return a reference to the originating executable who started the process when `dlopen` is called
2: `loadedlib1.so`
3: `loadedlib2.so`

Vs bionic's `dl_iterate_phdr`:

1: `null` < same as glibc, `dlopen` will get a referece to itself
2: `exec_test` < this won't count as an opened lib so `RTLD_NOLOAD` will make `dlopen` to ignore it
3: `loadedlib1.so`
4: `loadedlib2.so`

1. Potential solutions to this problem

1. 1. 1. Get the executable name and ignore that entry specifically.

I couldn't find a reliable way to get this. There are some SO responses suggesting calling `dl_iterate_phdr` and taking the first result, but I couldn't find documentation sustaining this. There may be even problems when this is running in a java environment.

1. 1. 1. Have a static variable that keeps the iteration repetition value.

But if this is called more than once then it fails. I don't think it is tho.

1. 1. 1. Ignoring any non-loaded dlopen.

The assumption here is that if something is returned by `dl_iterate_phdr` then it should be loaded, on bionic the executable is clearly the exception. It is loaded, you can get the reference by calling `dlopen(null…`, but the actual path that it is passing is not in the table of loaded libraries, so the call returns empty.

If the library is loaded, the conformances processed and then unloaded again, when the conformances are checked the memory will be deallocated and it's going to crash.

1. So...

Ignoring non loaded libraries sound like the safe path to me, because even if there's a conformance to be declared it will fail as soon as you want to access it. But we can totally be missing something.