`eglCreateWindowSurface` fails after updating to android 10

[OptimisticPeach]

I originally opened an issue on this in PistonDevelopers/glutin_window#178, but I feel like it would also be appropriate to post here, given that the error occurs while using a glutin_window api which calls a glutin api.

The code that crashes is as follows:

let window: GlutinWindow = WindowSettings::new(
        "rust app", (200.0, 200.0)
    )
    .fullscreen(true)
    .graphics_api(OpenGL::V2_1)
    .build()
    .unwrap();

It reports the following important lines:

BufferQueueProducer: [com.optimistic_peach.trees/android.app.NativeActivity#0] connect: already connected (cur=1 req=1)
libEGL  : eglCreateWindowSurface: native_window_api_connect (win=0x762d44c010) failed (0xffffffea) (already connected to another API?)
libEGL  : eglCreateWindowSurfaceTmpl:729 error 3003 (EGL_BAD_ALLOC)
RustAndroidGlueStdouterr: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: OsError("eglCreateWindowSurface failed")', src/libcore/result.rs:1084:5

Surrounding logcat information can be seen in PistonDevelopers/glutin_window#178, but it's mostly a crash dump of the process because of the SIGABRT sent by the os.

Some things to note:

• My opengles_version_major and opengles_version_minor keys in my Cargo.toml match the OpenGL version I ask for when creating the window.
• Changing the android or sdk version doesn't change the result (At least not noticeably)
• I've patched android_glue in every crate I depend on to use the one currently hosted on github, given the one on crates.io is ABI incompatible with what the cargo-apk on github expects. (cargo-apk on github doesn't work on windows due to command length limitations while calling the linker).
• To quote the second comment on the other issue:

  According to this page, and this entry, android has changed its egl specification to 1.5

I'd be happy to post some more debug information if necessary if the issue can't be diagnosed without it.

[goddessfreya]

cc @mb64 @philip-alldredge I figure you two have a good portion of familiarity w/ android. Any ideas what could be up?

[philip-alldredge]

Unfortunately, I do not. The error usually indicates an EGL surface has already been created.

This can happen if a previous surface has been destroyed while the context is still active. However, since this is happening during the initialization it doesn't appear to be the case.

Does the APK work on older versions of android?

Is this occurring as soon as the application is started?

[OptimisticPeach]

Does the APK work on older versions of android?

In the example of a snake game I made a while ago, it used to work fine on my device (At the time running android pie AKA android 9) but then once I'd updated it didn't work. I'll get an emulator running with android 9 to see if this specific APK works.

Is this occurring as soon as the application is started?

No, it happens when the call occurs. If I manually add a delay prior to running .build(), I end up with a black screen for the delay and then it crashes and dumps into logcat.

[philip-alldredge]

I was able to reproduce the issue using piston window and Android 9.

The issue is that it attempts to use OpenGL 2.1 and and then attempts to use OpenGL ES 2.1.

The problem is that OpenGL ES doesn't have a 2.1 version. I also attempted a plain glutin application and that crashes as well. However, the errors in that case were more helpful. I'm not sure why using glutin directly results in an invalid version/api message while using piston results in the message you received.

Switching the code to use OpenGL::V2_0 fixes the crash on my phone.

https://github.com/PistonDevelopers/glutin_window/blob/c9b89f3c8d60b5e8741c1700fd024b62c5ae4a91/src/lib.rs#L95

[philip-alldredge]

The reason for the difference in error could be that in my test with glutin I was specifying OpenGL ES as opposed to specifying the option to try to use GL and then ES.

[OptimisticPeach]

It can create the surface properly on android 9 (emulator), but later fails with thread '<unnamed>' panicked at 'called "Result::unwrap()" on an "Err" value: "No compatible vertex shader"' probably due to my incompetence setting up emulators. I'll try with OpenGL::V2_0 on android 10. As for that GlRequest::GlThenGles I'd originally suggested it in PistonDevelopers/glutinwindow#154 under the assumption that the api would search for the opengl version first and then load it, rather than try to load it, error out and the try to load opengles.

[OptimisticPeach]

Unfortunately running with OpenGL::V2_0 doesn't work either on android 10.

[OptimisticPeach]

The app gets to the same point on my android 10 emulator though which is interesting, given that it should be similar to my android 10 device I have sitting beside me.

[philip-alldredge]

I'm only using a simple application that creates a context. It doesn't use any shaders or try to render anything. Unfortunately, it is able to create the context on the emulator and I don't have an Android 10 device with which to test. Although I'm afraid this could vary between hardware devices.

[OptimisticPeach]

Upon further inspection with an emulator, I've inferred that it's got to do with my phone and that the vertex shader errors are occurring due to improper gles support with the emulator. Since the emulator is a pixel 2 emulator, and the device is a pixel 2, the reasoning must have to do with something other than the hardware.

[OptimisticPeach]

After delving into glutin/egl, I've secluded it to the following call:

https://github.com/rust-windowing/glutin/blob/c8bf4943f39e00a917c7f2d3da68ceaa4477b9d1/glutin/src/api/egl/mod.rs#L761-L766

Which returns EGL_BAD_ALLOC which is listed as having the reasons to fail in the docs: https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglCreatePlatformWindowSurface.xhtml (Note the eglCreateWindowSurface docs point to the eglCreatePlatformWindowSurface docs)

[OptimisticPeach]

The previous post has been sitting half-written on here for a day or two, so that's old new and I've got new stuff to report; Here we try twice with the first time being the default while the second time is a modified version (Probably for compatibility?):

https://github.com/PistonDevelopers/glutin_window/blob/master/src/lib.rs#L120-L129

But if I change that to:

let ctx = context_builder.build_windowed(window_builder, &events_loop)?;
let ctx = unsafe { ctx.make_current().map_err(|(_, err)| err)? };

We observe different errors, because we no longer toss out the first error (Which I think may cause the problem).

This time we get a OpenGlVersionNotSupported error here: https://github.com/rust-windowing/glutin/blob/c8bf4943f39e00a917c7f2d3da68ceaa4477b9d1/glutin/src/api/egl/mod.rs#L1308-L1315 If we see which of the two errors occur, it's the 3004 variant (Which is eglBadAttribute).

I don't have experience with egl at all, so all I can go off of are Java examples and docs which "omit things for brevity" 😬.

[goddessfreya]

Which returns EGL_BAD_ALLOC which is listed as having the reasons to fail in the docs:

I think there is a good chance android returns the same native handle when making a new window (as after all, an app can't have more than one window, maybe? Not really sure how things work on android, I must admit), which would explain piston failing on attempt #2 with EGL_BAD_ALLOC, see:

EGL_BAD_ALLOC is generated if there is already an EGLSurface associated with native_window (as a result of a previous eglCreatePlatformWindowSurface call).

---

If we see which of the two errors occur, it's the 3004 variant (Which is eglBadAttribute).

Right, so either the config id is invalid, or the context attributes. Likely the latter. I'd comment out everything that pushes into context_attributes minus the final context_attributes.push(ffi::egl::NONE as i32); and make sure that works. Once the one element context_attributes is confirmed to work, I'd manually go uncommenting things section by section until you discover which attribute breaks it (and if that attribute is conflicting with another attribute).

[OptimisticPeach]

Okay. I followed your suggestions, and the following lines are the problem: https://github.com/rust-windowing/glutin/blob/c8bf4943f39e00a917c7f2d3da68ceaa4477b9d1/glutin/src/api/egl/mod.rs#L1265-L1266 Commenting them out allows it to keep working (Or running in release mode, since its default value is dependent on the target).

Unfortunately, it still doesn't work, resulting in the same error as the emulators with a basic example (The piston spinning red square example).

RustAndroidGlueStdouterr: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "No compatible vertex shader"',

And the following in the OS stack trace (Rust stack traces seem to not work, but OS ones do):

backtrace:
      #00 pc 0005f2b6  /apex/com.android.runtime/lib/bionic/libc.so (abort+166) (BuildId: 68c87e04526a60689ecb5deb329804a0)
      #01 pc 000b2bc1  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (std::sys::unix::abort_internal::ha9c945fef06434ab+2)
      #02 pc 000b15f9  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (std::sys_common::util::abort::h70260f83d3dabfb8+44)
      #03 pc 000b215d  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (rust_panic+52)
      #04 pc 000b2057  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (std::panicking::rust_panic_with_hook::h73d7e71d825ee71c+230)
      #05 pc 000b1daf  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (std::panicking::continue_panic_fmt::h905214708b513597+94)
      #06 pc 000b1d13  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (rust_begin_unwind+2)
      #07 pc 000c558b  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (core::panicking::panic_fmt::h3a0f77f4517e6ed5+34)
      #08 pc 000c5617  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (core::result::unwrap_failed::h6b77a12f3125655f+62)
      #09 pc 00042f61  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (core::result::Result$LT$T$C$E$GT$::unwrap::hf1812842375253a6+104)
      #10 pc 0004085d  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (opengl_graphics::back_end::Colored::new::hd26a04b15c404d3e+516)
      #11 pc 00041a0f  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (opengl_graphics::back_end::GlGraphics::new::h0e0b5665a6014119+78)
      #12 pc 0001fd8d  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (android_base::app_container::AppContainer$LT$T$GT$::init::h567374951c83c132+368)
      #13 pc 0001a79d  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (trees::main::hd298e073ed1658cd+58)
      #14 pc 000111f1  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (trees::android_main::_$u7b$$u7b$closure$u7d$$u7d$::hb962460bd9a55d1a+4)
      #15 pc 00012071  /data/app/com.optimistic_peach.trees-E-QFDmkbH8KN4QLPTidNkg==/lib/arm/libtrees.so (cargo_apk_injected_glue::android_main2::main_thread::he39c3fd078bb48e7+24)
      #16 pc 000a6093  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+20) (BuildId: 68c87e04526a60689ecb5deb329804a0)
      #17 pc 00060763  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) (BuildId: 68c87e04526a60689ecb5deb329804a0)
service: engine paused

I'll try to find the source of that error (If it's even in glutin).

[OptimisticPeach]

Uh... Nevermind, that's happening in PistonDevelopers/opengl_graphics, which unfortunately doesn't support opengles... I guess I'll have to figure that one out too! Once something that takes care of the erroneous debug flag gets pushed this issue can probably be closed.

[OptimisticPeach]

It works now. I've made some changes to opengl_graphics to get it to work now, but the glutin/glutin-window side is done with the changes to the debug flag.