【问题标题】:How to catch "Fatal signal 11 (SIGSEGV)"?如何捕捉“致命信号 11 (SIGSEGV)”?
【发布时间】:2019-08-27 15:38:20
【问题描述】:

在我的 android OpenGL ES 项目中,我最近在我的着色器代码中有一个错误, 这显然在此处的 OpenGL 线程中导致了“致命信号 11 (SIGSEGV)”:

GLES32.glCompileShader(glShaderHandle);

我解决了这个错误,它又可以正常工作了,但是我很难找出那个错误是从哪里来的。当然,我会尝试“捕捉”这样的着色器错误:

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

但是在 SIGSEGV 错误的情况下,java 代码甚至没有达到这一点。尝试使用 try/catch 捕获错误也不起作用。该应用程序无论如何都会崩溃。我猜这个错误发生在原生 c 代码中。

有没有办法处理来自 java 代码的此类错误以防止应用崩溃?

【问题讨论】:

    标签: java android opengl-es segmentation-fault


    【解决方案1】:

    你抓不住它。这是一个段错误。它在 C 中崩溃。它不会变成 Java 堆栈跟踪,它被 linux 视为硬故障,应用程序立即终止。

    您也许可以编写一个 C 信号处理程序并进行一些处理,但我真的不推荐它。从此时起,您将无法以任何方式继续该应用程序,因为该应用程序现在处于未定义的行为中。

    如果您确实想尝试(我真的不建议这样做),请阅读 How to write a signal handler to catch SIGSEGV? 以了解问题的概述。

    【讨论】:

    • 这个段错误转储核心吗?是否可以分析核心文件以确定错误发生的位置,以获得类似 Java 堆栈跟踪的信息?
    • 您通常会在 logcat 中的该行下方获得部分转储
    • 但我真的不推荐它。出于调试目的,它似乎很好,为什么不呢?
    • @SomeName 因为它很难,所以要让它在不同风格的 linux 上运行更难,而且因为你在这种状态下实际上不能做太多事情——应用程序可以' t 实际上安全地继续并假设正在工作。你知道你至少有一个无效的指针,如果不是完全的内存损坏的话。您正在为它掷骰子,内存中的任何内容,包括应用程序代码本身,仍然有效。并且做错了会禁用已经存在的堆栈转储。
    • 好的。无论如何,这似乎是我手机的 OpenGLES 实现中的一个错误。当着色器代码出现错误时,不应该是分段错误,而是可以通过 GL_COMPILE_STATUS 读取的消息。我将研究信号处理程序以用于学习目的,但我不会在应用程序中实现它
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-10-05
    相关资源
    最近更新 更多