4

In my android OpenGL ES project i recently had an error in my shader code, which apparently caused a "Fatal signal 11 (SIGSEGV)" in the OpenGL Thread here:

GLES32.glCompileShader(glShaderHandle);

I resolved the error and it works fine again but I had a hard time finding out where that error came from. Of course I try to "catch" shader errors like this:

GLES32.glGetShaderiv(glShaderHandle, GLES32.GL_COMPILE_STATUS, result, 0);

But in the case of the SIGSEGV error, the java code didn't even get to that point. Also trying to catch the error with try/catch didn't work. The app crashes anyway. I guess the error happens in native c code.

Is there a way to handle errors like this from java code to keep the app from crashing?

genpfault
  • 51,148
  • 11
  • 85
  • 139
theCNG27
  • 405
  • 8
  • 27

1 Answers1

7

You can't catch it. This is a segfault. Its a crash in C. It doesn't turn into a Java stack trace, its treated as a hard fault by linux and the app is immediately terminated.

You may be able to write a C signal handler and do some processing, but I really wouldn't recommend it. And you would not be able to continue the app in any way from this point, as the application is now in undefined behavior.

If you do want to attempt that (I really don't suggest it) read How to write a signal handler to catch SIGSEGV? for an overview of the issues.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
  • Does this segfault dump core? Is it possible to analysis the core file to determine where the error occurred, to get something like a Java stack trace? – markspace Apr 05 '19 at 18:29
  • You generally to get a partial dump right under that line in the logcat – Gabe Sechan Apr 05 '19 at 18:30
  • _but I really wouldn't recommend it._ For debugging purpose it seems fine, why not? – Some Name Apr 05 '19 at 19:21
  • @SomeName Because its hard, doing it so that it works well across different flavors of linux is harder, and because you can't actually do much when you're in this state- the app can't actually continue safely and assume to be working. You know you have at least an invalid pointer, if not total memory corruption. You're rolling the dice for it anything in memory, including the application code itself, is still valid. And doing it wrong will disable the stack dumping that already exists. – Gabe Sechan Apr 05 '19 at 19:24
  • Alright. It seems to be a bug in the OpenGLES implementation of my phone anyway. When there is an error in the shader code, there shouldn't be a segmentation fault but a message that can be read via GL_COMPILE_STATUS. I will look into the signal handler for learning purposes but I will not implement it in the app – theCNG27 Apr 06 '19 at 10:41