Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
johnno1962 opened this issue Jul 10, 2017 · 3 comments
Closed

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

johnno1962 opened this issue Jul 10, 2017 · 3 comments
Labels
Android Platform: Android bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. runtime The Swift Runtime standard library Area: Standard library umbrella

Comments

@johnno1962
Copy link
Contributor

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
Copy link
Contributor Author

PR #10836 created to workaround this for now

@johnno1962
Copy link
Contributor Author

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
Copy link
Contributor

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. 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. 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. 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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Android Platform: Android bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. runtime The Swift Runtime standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

2 participants