java.lang.RuntimeException：eglSwapBuffers失败：EGL_SUCCESS

Question

I've an OpenGL application in the Google Play Store and I'm facing a daily exception:

java.lang.RuntimeException: eglSwapBuffers failed: EGL_SUCCESS
at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1085)
at android.opengl.GLSurfaceView$EglHelper.swap(GLSurfaceView.java:1043)
at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1369)
at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1123)

The problem is, on all my smartphones I cannot reproduce this error. I've already contacted Google for any device info, but they have none (so they say). The platform info in the exception is set to "OTHER".

I found some hints on the net that this error could be from a Samsung Galaxy Y device, and I found some suggestions to include:

android:configChanges="orientation|screenSize"

in the Android manifest file, but this does not work!

And of course I've the onPause and onResume handling implemented for my GL surface which, if not, produces other eglSwapBuffer problems.

Has anybody a solution for this problem?

Thanks!

Answer 1

No solution, just comment

For some reasons I can't comment the previous posts but I've some observations which perhaps could help.

We have the same problem and struggling to find a solution... We drastically reduced the size of our textures and now none is bigger than 1024x900 (don't forget the font ones). But we still need several ones and the problem is still there. We've pinpoint the problematic devices to the following ones:

Samsung Galaxy Y (GT-S5360 GT-S5360B GT-S5360L GT-S5363 GT-S5368 GT-S5369 SCH-I509 SCH-i509)
Samsung Galaxy Y Duos (GT-S6102 GT-S6102B GT-S6102E ivory)
Samsung Galaxy Ace (GT-S5830 GT-S5830B GT-S5830C GT-S5830D GT-S5830G GT-S5830L GT-S5830M GT-S5830T GT-S5830i GT-S5838 GT-S5839i GT-S6358 SCH-I619 SHW-M240S)
Samsung Galaxy Ace Duos (GT-S6802 GT-S6352 GT-S6802B SCH-I579 SCH-I589 SCH-i579 SCH-i589)
Samsung Galaxy Mini (GT-S5570 GT-S5570B GT-S5570I GT-S5570L GT-S5578 SGH-T499 SGH-T499V SGH-T499Y)
Samsung Galaxy Pocket (GT-S5300 GT-S5300B GT-S5302 GT-S5302B)

Also the error is reported in two flavors with different line numbers:

java.lang.RuntimeException: eglSwapBuffers failed: EGL_SUCCESS
    at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1099)
    at android.opengl.GLSurfaceView$EglHelper.swap(GLSurfaceView.java:1057)
    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1389)
    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1138)

java.lang.RuntimeException: eglSwapBuffers failed: EGL_SUCCESS
    at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1085)
    at android.opengl.GLSurfaceView$EglHelper.swap(GLSurfaceView.java:1043)
    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1369)
    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1123)

I don't know if I'm useful here, but in case it helps...

Answer 2

Your memory might be not enough to load all data at first. I met that problem too when making my game with AndEngine, too much Atlas with size bigger than 1024x1024 , data might be broken.

Answer 3

No solution, just observations.

The call to eglSwapBuffers returns false . The following error handling does not cope with the case that there is no error -- potentially it has not been set by EGL; OR the return value is wrong.

I did not find matching sources. These devices either run patched GLSurfaceView s (the stack trace search did not find anything...) or they use an in-between version (well, I don't know if 4.0.2 was official, grepcode contains only 4.0.1 and 4.0.3); OR I've missed something.

You have to track down which exact devices/android versions run into this problem. Then you could try to workaround this problem by providing a patched GLSurfaceView yourself, or using a different EGL config -- provided the problem can be fixed at all. There are bugs that are left unhandled for weeks; wondering what greater problems the responsible team faces...

Answer 4

The solution I ended up implementing was to add a global exception handler to catch this error (since it's thrown outside of any thread I have control over).

Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {...})

So at least the application doesn't crash and I can put up a message explaining the situation.