【log理解】是由于缺少read权限导致的crash吗?

ameyume ameyume 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年,写一次发全网 我也要 + 加入社区
gts测试log,如下红色部分,是由于前面的 fault addr 导致的crash,那fault addr是由于缺少 read 权限导致的吗?
还是与这个权限无关呢?
02-24 09:00:43.198 818 16229 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x35e in tid 16229 (HwBinder:818_3), pid 818 (drm@1.2-service)

02-24 09:00:43.195 818 818 W HwBinder:818_3: type=1400 audit(0.0:21338): avc: denied { read } for name="u:object_r:persist_debug_prop:s0" dev="tmpfs" ino=16940 scontext=u:r:hal_drm_widevine:s0 tcontext=u:object_r:persist_debug_prop:s0 tclass=file permissive=0

完整log:
02-24 09:00:43.151   818 16229 I WVCdm   : [cdm_engine.cpp(326):AddKey] CdmEngine::AddKey: sid178
02-24 09:00:43.151 818 16229 I WVCdm : [usage_table_header.cpp(144):AddEntry] UsageTableHeader::AddEntry: Lock
02-24 09:00:43.151 818 16229 I WVCdm : [usage_table_header.cpp(195):AddEntry] UsageTableHeader::AddEntry: usage entry #: 58
02-24 09:00:43.198 818 16229 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x35e in tid 16229 (HwBinder:818_3), pid 818 (drm@1.2-service)
02-24 09:00:43.198 818 16229 E libc : Access denied finding property "persist.debug.coredump"
02-24 09:00:43.195 818 818 W HwBinder:818_3: type=1400 audit(0.0:21338): avc: denied { read } for name="u:object_r:persist_debug_prop:s0" dev="tmpfs" ino=16940 scontext=u:r:hal_drm_widevine:s0 tcontext=u:object_r:persist_debug_prop:s0 tclass=file permissive=0
02-24 09:00:43.214 812 1561 E CHIUSECASE: [ERROR ] chxextensionmodule.cpp:613 MonitorThreadProcessing() open /proc/self/statm ret 0 mCameraOpen 1 buffer 808984 30557 15166 3 0 151612 0
02-24 09:00:43.214 812 1561 E CHIUSECASE:
02-24 09:00:43.237 16440 16440 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
02-24 09:00:43.240 1262 1262 I /system/bin/tombstoned: received crash request for pid 16229
02-24 09:00:43.241 16440 16440 I crash_dump64: performing dump of process 818 (target tid = 16229)
02-24 09:00:43.242 16440 16440 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-24 09:00:43.243 16440 16440 F DEBUG : Build fingerprint: 'meizu/m2081/m2081:10/QKQ1.200127.002/1582477560:user/release-keys'
02-24 09:00:43.243 16440 16440 F DEBUG : Revision: '0'
02-24 09:00:43.243 16440 16440 F DEBUG : ABI: 'arm64'
02-24 09:00:43.243 16440 16440 F DEBUG : Timestamp: 2020-02-24 09:00:43+0000
02-24 09:00:43.243 16440 16440 F DEBUG : pid: 818, tid: 16229, name: HwBinder:818_3 >>> /vendor/bin/hw/android.hardware.drm@1.2-service.widevine <<<
02-24 09:00:43.243 16440 16440 F DEBUG : uid: 1013
02-24 09:00:43.243 16440 16440 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x35e
02-24 09:00:43.243 16440 16440 F DEBUG : Cause: null pointer dereference
02-24 09:00:43.243 16440 16440 F DEBUG : x0 0000000000000000 x1 000000000000006b x2 00000000000000dc x3 000000003c6ef35f
02-24 09:00:43.243 16440 16440 F DEBUG : x4 000000000000660d x5 000000000019660d x6 000000000000000b x7 000000000000c146
02-24 09:00:43.243 16440 16440 F DEBUG : x8 00000076d0c5b440 x9 0000000000000001 x10 0000000000000001 x11 00000076ce805750
02-24 09:00:43.243 16440 16440 F DEBUG : x12 0000000000000000 x13 0000000000000001 x14 00000076ce805780 x15 000000000000009b
02-24 09:00:43.243 16440 16440 F DEBUG : x16 00000076d0c427a8 x17 00000076d06c7280 x18 0000000000000069 x19 0000000000000353
02-24 09:00:43.243 16440 16440 F DEBUG : x20 00000000c23f5008 x21 00000076d0bfd52f x22 000000000000044c x23 00000076d18b0000
02-24 09:00:43.243 16440 16440 F DEBUG : x24 00000076d0c5b5b8 x25 00000076d0bee0cf x26 00000076cc5ffb80 x27 000000005ff3a98d
02-24 09:00:43.243 16440 16440 F DEBUG : x28 0009850bc021bd88 x29 00000076cc5ffaf0
02-24 09:00:43.243 16440 16440 F DEBUG : sp 00000076cc5ffaf0 lr 00000076d18ae16c pc 00000076d18ae1cc
02-24 09:00:43.308 16440 16440 F DEBUG :
02-24 09:00:43.308 16440 16440 F DEBUG : backtrace:
02-24 09:00:43.308 16440 16440 F DEBUG : #00 pc 00000000000001cc <anonymous:76d18ae000>
02-24 09:00:43.357 1607 2544 W NativeCrashListener: Couldn't find ProcessRecord for pid 818
02-24 09:00:43.358 16440 16440 E crash_dump64: AM data write failed: Broken pipe
02-24 09:00:43.360 1262 1262 E /system/bin/tombstoned: Tombstone written to: /data/tombstones/tombstone_00
...全文

相关推荐

ERROR: Error in Log_event::read_log_event()

当从库尝试同步主库的binlog时,如果遇到`Error in Log_event::read_log_event(): ‘read error’`,可能的原因和解决方案包括以下几个方面:1.

weixin_38733414

从宕机到洞察:掌握Linux内核调试与Crash工具实战分析

在Linux系统运维与开发中,系统稳定性是核心诉求。当发生内核崩溃(Kernel Crash)时,常规的日志和用户态coredump往往失效,导致根因定位困难。其原理在于内核崩溃意味着系统控制权丢失,无法记录现场。为此,Linux提供了内核崩溃转储机制,通过Kdump在系统崩溃瞬间捕获完整物理内存的快照(vmcore),再使用专门的Crash工具进行离线分析,这构成了事后调试(Post-mortem Analysis)的技术基础。这项技术的核心价值在于能将黑盒般的系统宕机转化为可追溯、可分析的现场,实现从故

weixin_33841722

Linux内核崩溃分析:Crash工具从入门到实战

在Linux系统运维与内核开发中,系统崩溃(Crash)是常见且棘手的问题。不同于用户态程序调试,内核态崩溃往往导致系统完全停滞,传统调试器无法工作。为此,Linux社区发展出了专门的事后分析工具——Crash。它基于GDB引擎,但深度集成了内核数据结构知识,能够解析系统内存转储文件(vmcore),像法医一样解剖崩溃现场。通过Crash,工程师可以查看崩溃瞬间的CPU寄存器、进程堆栈、内核关键数据结构(如task_struct),精准定位空指针解引用、内存越界、死锁等问题的根源。掌握Crash工具,是运维

weixin_34279246

Linux内核崩溃分析实战:从Crash工具入门到高级调试技巧

在Linux系统运维和内核开发中,系统崩溃是常见且棘手的问题。当系统发生严重错误时,传统的日志调试方法往往失效,此时需要借助Crash工具进行事后调试。Crash工具通过分析内核内存转储文件,能够深入系统底层,定位崩溃根源。其核心原理在于利用调试符号文件解析内存数据结构,结合系统快照还原崩溃现场。这项技术对于诊断内存越界、空指针解引用、死锁等复杂内核问题具有极高价值,是运维工程师和内核开发者必须掌握的技能。在实际应用场景中,Crash工具常用于生产环境故障分析、内核问题排查和系统稳定性优化。本文将以实战为导

weixin_30719711

MTK系统DUMP之Crash-8.0.1工具

在使用Crash-8.0.1工具时,需要注意以下几点:- **权限要求**:由于涉及到系统级别的日志收集,该工具可能需要root权限才能正常运行。

鑫鑫缺点金
评论
收藏 已收藏
分享
返回顶部
ameyume
ameyume 领域专家: 操作系统技术领域 领域专家: 操作系统技术领域
Android 80,490 成员 91,375 内容