EGL_BAD_DISPLAY on Android OnePlus phones

Help
#1

Has anyone encountered this issue? If not, any advice is welcome for trying to track down the root cause.

When launching, first I see the error:

E/libEGL: validate_display:87 error 3008 (EGL_BAD_DISPLAY)

followed by a Signal 11/SIGSEV as soon as any rendering is attempted.

As far as I can tell, the segfault seems to happen in openfl

display._internal.CairoGraphics.hx:render

The issue appears to happen on at least the OnePlus Nord200 running Android 11, which has been reproduced on two different phones. Other (older) android devices I’ve tested don’t seem to exhibit the problem.

What I have tried:

  • Updating to the latest NDK (21.4.7075529 is the newest I can use and still get it to build)
  • Updating to the latest SDK (now targeting 31)
  • Updating to the latest lime/hxcpp/openfl

None of which appear to have any effect on the crash. Ive been chasing this problem for a couple of days now, and would welcome any insight into things to try, places to check, or hints about what could be the cause.

Thanks in advance!

[EDIT] I just tried the following:

  1. update to the latest openfl-samples
  2. openfl create PiratePig
  3. lime build android

Running the resulting PiratePig apk crashes with the same segfault on this device

#2

I don’t think it’s the same problem, but on Android 11 phone I have black screen with 64bit version of the game only.
In my case it doesn’t crash, game seems to work (touch, sound) except for the visual part.
The reason I found is target-sdk-version="30"
If I set it to 29, everything is fine.
I have validate_display:87 error 3008 (EGL_BAD_DISPLAY) in both cases, so that’s might be not an issue at all.

If it not the case for you, try 32bit vs 64bit, android-ndk-r21e vs android-ndk-r15c, Lime 7.9.0 vs Lime 7.8.0.
Hope it will help.

Extension-admob
#3

@pozirk Your problem is most likely caused by tagged pointers.

The link includes a small change you can make to the AndroidManifest.xml file to get back the API 29 behavior, even when you target API 30. This only further pushes back a change that will eventually be required, presumably in hxcpp.

#4

I can’t say whether the original issue in this thread is related to what pozirk brought up. I’d suspect that, if the game still ran fine on the other devices even when you set it to target SDK 31, it’s a different issue.

Assuming this to be unrelated to pozirk’s issue, it sounds like your phone may not support the graphics configuration that SDL is requesting.

If you’re comfortable making changes to lime’s native sources and recompiling, you can try printing the egl configs that your device supports, and compare them to the configuration that your game is requesting.

I did something similar some time ago, when I got the EGL_BAD_DISPLAY error on an android emulator. In my case, it turned out that the antialiasing property on the main window was the culprit. Here’s the change I made in order to debug this.

The DUMP_EGL_CONFIG define is set so that SDL will print out the egl config your game is requesting. The other code additionally prints out the egl configs available on the device. I don’t recall exactly how everything will look, but you can paste whatever it prints out here and I’d be happy to take a look.

#5

Hey Justin!
Thanks for the info.
I have EGL_BAD_DISPLAY both with API 29 and 30.
The only difference is with API 30 (and 31) I get black screen, still game is not crashing.
In your link they say about app crashing, this is not my case, might be @grazer’s case though, but then doesn’t seems to be because of EGL_BAD_DISPLAY error.

#6

Sorry, I should have clarified. I ran into issues with a black screen as well with API 30. The game didn’t actually crash until GC happened. But both the crashing and the black screen went away when I disabled tagged pointers. My experience, together with the fact that your issues only happen when you target API 30 or higher, make me suspect that yours is the same issue.

#7

I see, I will try to disable tagged pointers then.
Thank you!

#8

@pozirk disabling tagged pointers, did it help?
Right now i got the same problem and for me the first indication i got is that it doesnt help. (still trying to figure out what goes wrong)

Did you find solution?

#9

Hey!
Sorry, didn’t have time yet.
I’m busy with some other things.
I’ll post here, when I get to it.
Google Play still should accept API 29 apps.

#10

Google is now requiring API 30 since last month, FWIW: https://developer.android.com/distribute/play-policies#APILevel30

@pozirk & @justin_espedal - thanks for the assistance, disabling tagged pointers with API 30 seems to have resolved the issues I was having.

#11

So
<application android:allowNativeHeapPointerTagging="false">
fixed my problem with black screen on 64bit version.

But as @justin_espedal said it should be fixed properly.
Any way to confirm if it’s hxcpp issue, so we can open a ticket then in Github?

1 Like
Moving to Android SDK 30
#12

Just to confirm I have a same problem with target API 30 and tested on Android 11.
Same version works fine on Android 9 and 10.
It’s hard to confirm if this is hxcpp problem as there is no crash, just a blank screen .

#13

Ok, could be this related with NaN-boxing ? ( if hxcpp use something similiar )

Probably this could also fix the problem with ios 15 crash ( discussed here https://community.stencyl.com/index.php?issue=2024.0)

Here is discussion about the same problem for Android ( mention NaN-boxing) :

#14

Damn it, iOS 15 crash!
I was receiving complaints from some users, but everything works fine on my test iPhone.

#15

The crash for iOS 15 is only for iPhone 12 (and maybe iPhone 13) - the new CPU.

I think the problem is with some type of memory boxing in hxcpp, but it’s hard to guess where .

Maybe a issue in hxcpp repository with reporting a bug and a question about some memory boxing could give some reference.

#16

Also latest iPad 9…

#17

To me it’s more like both problems are with Lime, and SDL, which is part of Lime.
I’ll open tickets on Github, but I guess @singmajesty has to look into it to be fixed.