system server crash//Android 信号

最新推荐文章于 2025-01-14 00:29:57 发布
最新推荐文章于 2025-01-14 00:29:57 发布
阅读量378 收藏
点赞数
文章标签： 移动开发
本文深入探讨了Android系统中信号处理的定义、行为及其来源，并详细分析了C++ Crash、Java Crash等现象背后的信号机制，为开发者提供了一种理解系统异常的新视角。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

iteye_3941
关注
Android V 挂起线程超时导致system_server挂掉
m0_61097519的博客
11-09 375
Android V 挂起线程超时导致system_server挂掉
Android Framework system_server进程启动
weixin_51139372的博客
03-26 859
前言：system_server 是系统核心服务的一个进程，这个进程包含了系统中核心Service的运行，给系统提供如：Window的管理、Activity的管理，哈喽大家我是Zzz.今天分享的blog是system_server进程的启动，环境基于aosp13_r6，话不多说直接上干货。最后在启动完各个service后，他还会调用Service的systemReady方法。系统的核心功能都在System_server中；这里可以看到是args.startClass。
Android5.0L下因sensorservice crash导致systemserver重启的另外一种场景分析
宋金时的专栏
07-03 3771
一、出问题的场景1、Sensorservice线程正在处理compass sensor事件的过程中，检查了一次buffer的指针的有效性，并在稍后会传递到AKM获取数据的函数接口中使用2、Sensorservice线程所在进程的负责跨进程通信的Binder线程在sensorservice线程检查buffer指针之后没有真正使用之前，收到了disable compass sensor的请求，从log
Android 9 Can‘t write: system_server_crash
ldswfun的专栏
11-23 1863
Android系统源码开发系列教学视频链接： Android 10.0 AOSP源码编译： AOSP源码开发环境搭建教学视频-百问100ask Android系统 10.0 AOSP源码编译--优快云程序员研修院 Android 10.0 根文件系统和编译系统： Android根文件系统和编译系统教学视频-百问100ask Android 10.0 根文件系统和编译系统-优快云程序员研修院 前言 　　　在Androi...
Android平台程序崩溃的类型及原因列举
agei98218的博客
07-20 678
Android平台程序崩溃大家都应该遇到过，force close和ANR应该是大家遇到较多的。 这里把Android平台程序崩溃的各种类型做一个简述和原因列举。 1.ANR（可见ANR）： 发生场景：应用发生ANR。 崩溃症状：系统弹出窗口询问用户选择“Force Close”或者“Wait”。 “Force Close”将杀掉发生ANR的应用进程。“Wait”...
system_server crash现象研究
亮子的专栏
12-21 1199
system_server crash现象研究 分类： android debug 2011-11-03 09:56 1162人阅读 评论(1) 收藏 举报 现象：当system server进程crash时,发现zygote进程会被杀掉，此后Zyogote进程和system server被重新启动。 分析：在init解析init.rc时，Zygote进程作为
android /system,android系統崩潰/system/lib/libhwui.so
weixin_39619451的博客
05-27 1932
我有時會碰到崩潰，它似乎是jni崩潰，但我的應用程序沒有任何jni代碼。這是一個圖形應用程序，並會加載一些圖片。android系統崩潰/system/lib/libhwui.so任何人都可以告訴我如何找到問題。什麼是libhwui.so。I/DEBUG ( 141): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 000000e8I/D...
案例1-CarService频繁crash导致system_server watchdog超时
weixin_44901612的博客
01-14 393
等到下次开机，用户解锁时 UsageStatsService 又会将这些记录从持久化存储读出来通过 android.bg 线程进行分发，假如一条记录需要 1ms，100000 条记录就需要 100s，这样就会导致 android.bg 线程持锁 mLock 一直处理消息，其他线程无法拿到 mLock 触发 system_server Watchdog 超时重启，而且重启设备也无法生效；UsageStatsService 会将事件封装为 Event：包含事件类型，包名和时间戳。
android system crash 总结
04-16
android system 多种crash现象分析总结。结合实际项目理解思路
【野fd问题】野fd导致system_server发生crash问题
pxy的博客
03-07 1558
1、问题描述不同类型测试均发生system_server native crash问题。2、问题分析log如下：pid: 3421, tid: 3515, name:PowerManagerSer  >>>system_server <<<signal 6 (SIGABRT), code -6 (SI_TKILL),fault addr --------Abor...
Android9.0 SystemServer Crash问题总结
weixin_44205232的博客
09-04 676
SystemServer Crash问题总结
长按power键的流程&&PhoneWindowManager的nullpointexception导致system_server crash 导致系统重启
淡淡的宁静的博客
06-12 730
前面的事件派发过程就跳过了，从PhoneWindowManager开始说起 安全模式简述 android平台，在长按power / menu键时会快速进入一个模式选择，部分定制的平台是直接进入安装模式，也可以定制成公司需要的一些特定功能模式，比如报警 ... power 也属于全局的特殊按键，同样在PhoneWindowManager.java中被捕获处理。 Po...
MTK system_server 卡死导致手机重启案例分析
程序员Android
07-30 2159
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、MTK AEE Log分析工具二、AEE Log分析流程三、system_server 卡死案例分析及解决本文主要针对Exception Type: system_server_watchdog,system_server卡死找出的分析以及解决方案。一、MTK AEE Log分析工具MTK AEE...
android资深工程师如何分析system_server异常
ming15920的博客
08-04 1322
如果System Server的CPU占用率一直很高，可能是System Server在进行一些高负载的操作，如执行密集计算或者大量的逻辑推理等。工具使用：利用AndResGuard等工具对System Server相关资源进行优化，以及使用Remdesivir等工具对System Server进行安全增强，这可以帮助我们在不影响System Server运行的情况下，检查其性能和安全性。分析系统重启原因：了解System Server是否有过重启历史，重启的原因是什么，这有助于找到问题的可能原因。
android 崩溃流程,理解 Android Crash处理流程(2)
weixin_35344136的博客
05-31 1319
9.2.1 app.kill[-> ProcessRecord.java]void kill(String reason, boolean noisy) {if (!killedByAm) {Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "kill");if (noisy) {Slog.i(TAG, "Killing " + toSho...
AMS： native crash处理
卓越之路
09-03 380
system_server启动过程会建立一个socket，其他进程出现crash，debuger进程会把收集到的信息发送给AMS中的crash处理线程。 // file: private void startOtherServices() { final Context context = mSystemContext; VibratorService vibrator = null; IStorageManager storageManager
Android系统构架及Native Crash
yokii_的博客
09-27 2242
一、引言     Android系统非常庞大、错综复杂，其底层是采用Linux作为基底，上层采用包含虚拟机的Java层以及Native层，通过系统调用(Syscall)连通系统的内核空间与用户空间。用户空间主要采用C++和Java代码，通过JNI技术打通用户空间的Java层和Native层(C++/C)，从而融为一体。     Google官方提供了一张经典的四层架构图，从下往上依次分为L
02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] Runtime aborting... 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] Dumping all threads without mutator lock held 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] All threads: 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] DALVIK THREADS (133): 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] "main" prio=6 tid=1 Runnable 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] | group="" sCount=0 ucsCount=0 flags=0 obj=0x718b9370 self=0xa9f66e00 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] | sysTid=1908 nice=-2 cgrp=foreground sched=0/0 handle=0xaa3c4470 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] | state=R schedstat=( 0 0 0 ) utm=303 stm=160 core=3 HZ=100 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] | stack=0xbe585000-0xbe587000 stackSize=8188KB 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] | held mutexes= "abort lock" "mutator lock"(shared held) 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] native: #00 pc 00373285 /apex/com.android.art/lib/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+76) 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] native: #01 pc 0044a5bb /apex/com.android.art/lib/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, bool, BacktraceMap*, bool) const+214) 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] native: #02 pc 0046200b /apex/com.android.art/lib/libart.so (art::DumpCheckpoint::Run(art::Thread*)+650) 02-21 18:45:59.833 1908 1908 F system_server: runtime.cc:669] native: #03 pc 0045d4bd /apex/com.android.art/lib/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+352) 02-21 18:45:59.833 1908
最新发布
03-08
<think>好的，我现在需要帮助用户查找Android系统服务器运行时崩溃的原因和解决方案，特别是涉及runtime.cc:669、Dalvik线程、dumpstack和libart.so的问题。首先，我应该回忆一下相关的知识，并结合用户提供的引用内容进行分析。 用户提到了引用[1]中的runtime.cc相关错误，这可能涉及到JNI调用的问题。在JNI环境中，错误的调用可能导致系统服务崩溃，比如调用静态方法时参数不匹配或者类加载器问题。引用[2]中提到使用jdb调试时在onCallback方法断点导致崩溃，这可能与回调处理中的异常有关，如死锁或资源竞争。引用[3]则指出内存不足导致编译失败，虽然这是编译时的错误，但运行时内存不足也可能引发system_server崩溃，需要留意内存泄漏或资源耗尽的情况。 接下来，我需要整理可能导致system_server崩溃的常见原因，包括JNI错误、Dalvik/ART运行时异常、内存问题、堆栈溢出等。针对每个原因，结合用户提供的线索进行分析。例如，runtime.cc:558的JNI调用错误可能暗示当前问题与JNI方法调用有关，需要检查是否有错误的JNI方法参数或未正确处理的异常。而引用[2]中的调试断点导致崩溃可能指向多线程问题或回调中的逻辑错误。 然后，解决方案部分需要分步骤说明，例如检查JNI代码、分析堆栈跟踪、监控内存使用、调试多线程问题等。同时，需要指导用户如何获取更多日志，比如使用adb logcat或tombstones，以及使用调试工具如gdb或addr2line来分析native层崩溃。 最后，生成的相关问题应覆盖根本原因分析、日志分析工具、常见错误类型、预防措施等，帮助用户进一步探索和解决问题。</think>关于Android system_server运行时崩溃（runtime.cc:669）的原因及解决方法分析如下： ### 一、根本原因分析 1. **JNI调用异常** 当出现`runtime.cc:558] native: #41 pc 0006c99b`类错误时，通常与JNI层到Java层的跨语言调用有关，如： - 未正确匹配JNI方法签名 - 在错误的线程上下文调用JNI方法 - 类加载器不一致导致的类查找失败[^1] 2. **Dalvik/ART运行时异常** `libart.so`相关错误常伴随： ```c void DumpNativeStack(std::ostream& os, pid_t tid) { // runtime.cc:669 ``` 可能涉及： - 堆栈溢出（StackOverflowError） - 内存访问越界（SIGSEGV） - 线程死锁或资源竞争 3. **内存资源耗尽** 根据Android编译错误经验[^3]，需排查： - system_server进程内存泄漏 - 共享内存资源耗尽（ashmem、binder内存） - FD泄漏导致打开文件数超过限制 ### 二、具体排查步骤 1. **获取完整崩溃日志** ```bash adb logcat -b crash -d > crash.log adb shell cat /data/tombstones/tombstone_00 > tombstone.log ``` 2. **分析关键堆栈信息** 重点关注以下标识： ```log Build fingerprint: 'Xiaomi/sagit/sagit:7.1.1...' signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) backtrace: #00 pc 0006c99b /system/lib/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod+30) #01 pc 00012345 /system/lib/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+216) ``` 3. **使用addr2line定位符号** ```bash arm-linux-androideabi-addr2line -e libandroid_runtime.so 0006c99b arm-linux-androideabi-addr2line -e libart.so 00012345 ``` ### 三、解决方案建议 1. **JNI问题修复** - 验证所有JNI方法签名： ```java // Java方法签名示例 public static native void nativeMethod(int param); ``` 对应JNI实现： ```c JNIEXPORT void JNICALL Java_com_example_NativeClass_nativeMethod(JNIEnv*, jclass, jint); ``` 2. **内存问题排查** - 使用`procrank`监控内存： ```bash adb shell procrank | grep system_server ``` - 检查binder状态： ```bash adb shell dumpsys meminfo system_server | grep -A10 "Binder" ``` 3. **多线程问题调试** 对于引用[2]的调试crash问题： ```bash # 附加gdbserver adb forward tcp:5039 tcp:5039 gdbclient.py -p [system_server_pid] (gdb) b art::Thread::DumpStack ``` ### 四、预防措施 1. 增加系统服务监控： ```xml <!-- frameworks/base/core/res/res/values/config.xml --> <bool name="config_enableSystemServerHeapDump">true</bool> ``` 2. 开启StrictMode检测： ```java StrictMode.setVmPolicy(new VmPolicy.Builder() .detectLeakedClosableObjects() .penaltyLog() .build()); ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值