Android, nativeRunMain() fails on some phone with arm64-v8a

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Android (All), All

Comments on the original bug report:

On 2017-12-14 21:44:28 +0000, Sylvain wrote:

When compiled in arm64-v8a and run on Huawei P8 Lite (available on google Pre-Launch report), nativeRunMain() fails with the error message:

nativeRunMain(): Couldn't load library libmain.so

A call to dlerror() tells:

dlopen failed: library "libmain.so" not found

The same arm64-v8a APK works on other arm64 phones.
The arm-v7a APK is working on the same P8 Lite and other phones.

As a work-around, I replaced the nativeRunMain() by a simpler implementation (calling directly main() from libmain.so). And that worked ...

On 2018-01-10 09:09:44 +0000, Sylvain wrote:

it failed at:

https://hg.libsdl.org/SDL/file/43bba409e6d2/src/core/android/SDL_android.c#l417

On 2018-01-15 18:01:13 +0000, Sam Lantinga wrote:

Can you see why it's failing?

On 2018-01-15 19:04:21 +0000, Sylvain wrote:

There only error I got from logcat of android console is:

12-14 12:40:46.979: E/SDL(16171): nativeRunMain(): Couldn't load library libmain.so

Maybe a bug on manufacturer side...
Also some basic SDL logcat lines seems missing.

Any idea what to test ? I'll give another try tomorrow

On 2018-01-16 10:41:28 +0000, Sylvain wrote:

Still failing on p8 lite with arm64-v8a abi.

To have all logs from logcat, I had to turn verbose/information into error message. And it appears the code flow is correct.

First failure happens at dlopen("libmain.so", RTLD_GLOBAL);

• Changing the flags to "RTLD_NOW | RTLD_LOCAL" also fails.
• Trying no to load twice the same library (I removed the load from java), and it still failing.

For the record, device configuration is:
Screen size 720 x 1280
Test Duration 300 seconds
Screen density (dpi) 320
Model Name P8 Lite
RAM 2048 MB
Manufacturer Huawei
OpenGL ES Version 2.0
Android Version Android 5.0
Native platform armeabi-v7a
Locale es_US
CPU Make HiSilicon
CPU Model Hi6220

From java:
Device: hwALE-H
Model: ALE-L23
supported ABI: arm64-v8a
supported ABI: armeabi-v7a
supported ABI: armeabi

On 2018-01-16 19:08:41 +0000, Sam Lantinga wrote:

Can you check the library load path (maybe LD_LIBRARY_PATH environment?) and list the files on disk?

Are there any environment variables to enable debug output from the library loader?

On 2018-01-16 19:09:22 +0000, Sam Lantinga wrote:

Can you try dlopen() of libmain.so from libmain.so?

On 2018-01-16 21:04:54 +0000, Sylvain wrote:

LD_LIBRARY_PATH is empty. But there's a similar logcat message:

Setting context classloader to 'dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/com.google.android.apps.mtaas.crawler-1/base.apk", zip file "/data/app/net.app.myapp-1/base.apk"],nativeLibraryDirectories=[/data/app/net.app.myapp-1/lib/arm64, /vendor/lib64, /system/lib64]]]', Original: 'dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/com.google.android.apps.mtaas.crawler-1/base.apk", zip file "/data/app/net.app.myapp-1/base.apk"],nativeLibraryDirectories=[/data/app/net.app.myapp-1/lib/arm64, /vendor/lib64, /system/lib64]]]'

From java, in the directory "getContext().getApplicationInfo().nativeLibraryDir)" (eg /data/app/net.app.myapp-1/lib/arm64),
there are libraries: libmain.so, libSDL2.so, libSDL2_image.so, etc.

It's coherent.

from libSDL2.so:
dlopen("libmain.so", ) = fail
dlopen("libSDL2.so", ) = fail
dlopen("libSDL2_image.so", ) = fail
dlopen("libGLESv2.so", ) = ok

DL_DEBUG exists but doesn't seem to work when set from app.

I reported a bug for this pre-launch test report as it appears to be a bug in this device.

On 2018-01-17 04:36:40 +0000, Sam Lantinga wrote:

Yes, it definitely sounds like a bug in that device.

On 2018-08-06 21:20:20 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.

On 2018-09-04 07:04:14 +0000, Sylvain wrote:

Reopening the issue as I was sent some explanation and a fix.

The issue is totally reproducible on P8 Lite.

"The dlopen() call doesn't include the app's native library directory. The behavior of dlopen() by Android is not guaranteed".

Workaround in getMainSharedObject()

Just replace
return library;
with
return getContext().getApplicationInfo().nativeLibraryDir + "/" + library;

On 2018-09-05 22:56:08 +0000, Sam Lantinga wrote:

Patch added, thanks!
https://hg.libsdl.org/SDL/rev/d9e69bf4c6d4