bugly之SIGSEGV(SEGV_MAPERR)问题定位及解决

SIGSEGV(SEGV_MAPERR)

记录一下关于我在项目中遇到 SIGSEGV(SEGV_MAPERR) 异常引起原因。

在 POSIX 兼容的平台上，SIGSEGV 是当一个进程执行了一个无效的内存引用，或发生段错误时发送给它的信号。SIGSEGV 的符号常量在头文件 signal.h 中定义。因为在不同平台上，信号数字可能变化，因此符号信号名被使用。通常，它是信号11。

对于不正确的内存处理,如当程序企图访问 CPU 无法定址的内存区块时,计算机程序可能抛出 SIGSEGV。操作系统可能使用信号栈向一个处于自然状态的应用程序通告错误，由此，开发者可以使用它来调试程序或处理错误。
在一个程序接收到 SIGSEGV 时的默认动作是异常终止。这个动作也许会结束进程，但是可能生成一个核心文件以帮助调试，或者执行一些其他特定于某些平台的动作。
SIGSEGV可以被捕获。也就是说，应用程序可以请求它们想要的动作，以替代默认发生的动作。这样的动作可以是忽略它、调用一个函数，或恢复默认的动作。在一些情形下，忽略 SIGSEGV 导致未定义行为。
一个应用程序可能处理SIGSEGV的例子是调试器，它可能检查信号栈并通知开发者目前所发生的，以及程序终止的位置。

SIGSEGV通常由操作系统生成，但是有适当权限的用户可以在需要时使用kill系统调用或kill命令（一个用户级程序，或者一个shell内建命令）来向一个进程发送信号。

在我研究了两天后，发现该异常并不会引起app闪退，然后我就猜测是某条后台服务出现了问题。因为我的项目中有一条录屏Service，占用系统资源较高，频繁被系统杀死，所以我推断出当Service被系统杀死时，bugly就会上传此条崩溃记录。如果该Service比较重要时，只需要去按照网上的方法做一个Service保活即可。

当然，这只是我在项目中遇到的问题，也许其他问题也会引起此异常记录，大家参考一下即可。