兰州 网站制作,国外优秀网页设计网站,保定 网站建设软件开发,网站查询域名入口一、前言
Android系统类问题主要有stability、performance、power、security。Android集成一个守护进程tombstoned是android平台的一个守护进程#xff0c;它注册成3个socket服务端#xff0c;客户端封装在crash_dump和debuggerd_client。 crash_dump用于跟踪定位C crash它注册成3个socket服务端客户端封装在crash_dump和debuggerd_client。 crash_dump用于跟踪定位C crash debuggerd_client用于在某些场景发生ANRwatchdogshell执行debuggerd -bdump指定进程 的backtrace。 二、tombstone原理
1ELF程序加载过程 在进入execve()系统调用之后Linux内核就开始进行真正的装配工作。在内核中execve()系统调用相应的入口是sys_execve()。sys_execve()进行一些参数的检查复制之后调用do_execve()。do_execve()会首先查找被执行的文件如果找到文件则读取文件的前128个字节。文件的前128个字节保存着可执行文件的格式信息特别是前四个字节魔数。这样可以根据不同的可执行文件信息来调用不同的装载模块。当do_execve()读取了这128个字节的文件头部之后然后调用search_binary_handle()去搜索和匹配合适的可执行文件装载处理。linux中所有被支持的可执行文件格式都有相应的装载处理过程。search_binary_handle()会通过判断文件头部的魔数确定文件的格式并且调用相应的过程。ELF可执行文件的装载处理过程叫做load_elf_binary()。load_elf_binary()被定义在fs/Binfmt_elf.c。它的主要步骤是
1. 检查ELF可执行文件格式的有效性比如魔数程序头表中段Segment的数量
2. 寻找动态链接的“.interp”段设置动态连接器路径与动态链接有关
3. 根据ELF可执行文件的程序头表的描述对ELF文件进行映射比如代码、数据、只读数据。
4. 初始化ELF进程环境比如进程启动时EDX寄存器的地址应该是DT_FINI的地址。
5. 将系统调用的返回地址修改成ELF可执行文件的入口点这个入口点取决于程序的链接方式对于静态链接的ELF可执行文件这个程序入口就是ELF文件的文件头中e_entry所指的地址对于动态链接的ELF可执行文件程序入口点是动态连接器。
当load_elf_binary()执行完毕返回至do_execve()再返回到sys_execve()上面的第5步中已经把系统调用的返回地址改成了被装载的ELF程序的入口地址了。所以当sys_execve()系统调用从内核态返回到用户态时EIP寄存器存放下一个机器指令的地址, 直接跳转到了ELF程序的入口地址了于是新的程序开始执行ELF可执行文件装载完成。 在 execve() 执行过程中系统会清掉 fork() 复制的原程序的页目录和页表项并释放对应页面。系统仅为新加载的程序代码重新设置进程数据结构中的信息申请和映射了命令行参数和环境参数块所占的内存页面以及设置了执行代码执行点。此时内核并不从执行文件所在块设备上加载程序的代码和数据。当该过程返回时即开始执行新的程序但一开始执行肯定会引起缺页异常中断发生。因为代码和数据还未被从块设备上读入内存。此时缺页异常处理程序会根据引起异常的线性地址在主内存区为新程序申请内存页面内存帧并从块设备上读入引起异常的指定页面。同时还为该线性地址设置对应的页目录项和页表项。这种加载执行文件的方法称为需求加载Load on demand。 2Android Linker
无 --dynamic-linker编译参数的ELF文件会加载为静态可执行程序如init进程: Android大部分可执行程序使用linker做动态连接器编译时候加上参数 --dynamic-linker 除了init进程recoveryadbd进程也没有配置--dynamic-linker链接器。他们在Android.mk里面声明LOCAL_FORCE_STATIC_EXECUTABLE : true或者在Android.bp声明static_executable: true。静态可执行程序不能加载libc等动态库只能导入static_libs。以上都是针对ELF格式的程序。
当然/system/bin/linker也是静态连接的。他自己不能配置为动态链接器。Linker的Android.bp里面配置static_executable: true。同时根据arch编译汇编代码 begin.S来配置程序入口。Arm64汇编指令 bl:跳转指令,但是在跳转之前,会将下一条指令保存到返回地址(链接寄存器LR寄存器中。Br与bl类似只是后面参数需要特定的寄存器。 3Android Linker 拦截信号
应用程序注册信号处理hanlder当信号事件发生后内核将信号置为pending状态在中断返回或者系统调用返回时查看pending的信号内核在应用程序的栈上构建一个信号处理栈帧然后通过中断返回或者系统调用返回到用户态执行信号处理函数。执行信号处理函数之后再次通过sigreturn系统调用返回到内核在内核中再次返回到应用程序被中断打断的地方或者系统调用返回的地方接着运行。 debuggerd_signal_handler()函数最开始使用互斥锁 pthread_mutex_lock() 来保护线程方式同一时间多个线程处理信号而导致冲突。接着调用 log_signal_summary() 来输出一些log 信息信息例如fault addr、signo、signame、pid、tid、线程名、主线程名等。
接着调用clone() 函数创建伪线程并在伪线程中调用 debuggerd_dispatch_pseudothread() 函数原来的线程原地等待子线程的开始和结束。
如果应用程序没有注册对应的信号处理函数那么信号发生后内核按照内核默认的信号处理方式处理该信号。
debuggerd_dispatch_pseudothread() 线程中会 fork 一个子进程并通过 execle() 系统调用去执行 crash_dump64 程序父进程等待 crash_dump64 进程退出。 4LINUX信号
当程序运行出现异常时候CPU会发出指令异常信号。非可靠信号由linker注册。Linker加载的动态可执行程序即使被加载程序调用了注册函数函数也不能正常收到因为这些信号已经提前被被linker截断。 中断信号的产生有以下4个来源1,外设(来自中断控制器); 2,IPI(处理器间中断); 3, CPU异常比如前一条指令存在除零错误、缺页错误等; 4,中断指令。前两种中断都可以叫做硬件中断都是异步的后两种中断都可以叫做软件中断都是同步的。在arm64架构加将上述中断分类为异步异常Physical interrupts和Virtual interrupts和同步异常同步异常与当前指令的执行直接相关。其实大同小异。以上是CPU层面的对于LINUX来说以上描述的异常或者中断都代表一次hardirq。当然hardirq可能产生一个softirq到软中断pending列表或者直接被处理返回。Linux的软中断是进程调度层面的由内核线程softirqd去读取软中断pending列表再转化为信号分发。当一个进程收到一个信号的时候进程会被挂起开始执行中断处理函数。Linux操作系统当中有62个信号前31个1-31不可靠信号非实时信号信号有可能丢失后31个34-64可靠信号信号不会丢失。非可靠信号注册多次只会处理第一次注册的可靠信号注册多次会处理多次。Linux处理软中断处于程序上下文。处理硬中断处于中断上下文。 5crash dump流程 在 crash_dump64 进程中再fork 一个新进程父进程通过 fork_exit_read 去等待子进程子进程继续执行 crash_dump 的任务。
在 crash_dump64 中通过 /proc/PID/cmdline 获取进程的名字通过 /proc/PID/fd 获取此进程打开多少文件每个文件都有一个描述符。
在 crash_dump64 中循环遍历这个进程中所有的线程对进程中的每一个线程进行 ptrace 操作对目标线程读取器 crashinfo。crashinfo 读取完毕后 detech 当前的线程。
之后在 crash_dump64 中调用 tombstoned_connect() 通过 socket 连接到 tombstoned 进程。根据 signal 的 si_val 的值做不同的判断为0时 dump tombstone为1时 dump backtrace。
如果是 dump tombstone最终 tombstone 通过 engrave_tombstone() 函数生成engrave_tombstone() 函数的第二个参数 unwinder 是输出 backtrace 等信息的关键函数。unwinder 初始化过程中获取了当前进程的内存和 memory map这些信息会在后面帮助 debuggerd 生成 tombstone 文件。 dump_memory_and_code() 打印寄存器附近的memory 信息。 dump_signal_info() 函数打印引发这次 tombstone 的信号信息摘要。 dump_probable_cause() 通过分析 signal_info 打印可能的原因信息。如果没有分析出可能的原因就不会打印出任何信息。 dump_abort_message() 通过内存信息确定 abort message。 dump_registers() 打印出错时寄存器的值thread_info 中记录了错误发生时的寄存器信息。 log_backtrace() 调用栈。 dump_memory_and_code() 打印寄存器附近的memory 信息。 dump_all_maps() map 信息记录了进程对应的内存映射包括开始地址长度访问权限文件描述符offset 等信息。 6debug dump trace 流程
Debug dump的触发场景一般是system_server发生watch dog或者系统执行“debuggerd –b [pid]”命令产生。分别是调用进程加载组件debuggerd_client的接口: dump_backtrace_to_file(), 或者JNI接口: android_os_Debug_dumpJavaBacktraceToFileTimeout(), android_os_Debug_dumpNativeBacktraceToFileTimeout()。 信号会对系统调用产生影响触发系统调用的自动重启动。
debuggerd_trigger_dump向“tombstoned_intercept”发送InterceptRequest 请求tombstone中的intercept_manager 处理该请求并返回intercept的状态如register/started/failed等。
然后向目标进程发送信号signal (dump_type kDebuggerdJavaBacktrace) ? SIGQUIT : DEBUGGER_SIGNAL; --- #define DEBUGGER_SIGNAL (__SIGRTMIN 3)。
之后等待tombstoned的信息返回。 7Crash dump与debug dump整体流程
异常发生时, ARM 处理器会跳转到对应该异常的 固定地址 去执行异常处理程序, 这个 固定的地址 就是异常向量。对于tombstone类异常会产生一个Software interrupt (SWI)。每个cpu会有一个内核线程softirqd轮询读取软中断并把信号转发给对应的应用。除了SWIARM还会产生ResetUndefined instructionsPrefetch Abort (instruction fetch memory abort) Data Abort (data access memory abort)IRQ (interrupt)以及FIQ (fast interrupt)。Arm64会产生Synchronous exceptionSerrorIRQ FIQ四个类型的同步异常。不同架构中断与异常代码流程底层差异比较大。除了底层上报还有各个应用程序可以给其他应用发送信号由操作系统调度。 三、LOG解析
1debugdump 一般问题不会是libc.so或者libhwbinder.so这种经过多年检验的公共库。找到与问题版本对应的符号产物。本地复现的在符号在out/ 目录里 symbols/ 目录下或者在编译后的工程先source 和lunch之后再用addr2line
addr2line -f –a -C -e
./symbols/vendor/bin/hw/android.hardware.audio2.0-service 00001771 2crashdump 四、示例
1权限问题导致SIGABRT 检查main log有如下selinux打印
07-18 17:48:44.679 6105 6105 W Binder:6105_2: type1400 audit(0.0:3532): avc: denied { read write } for namehab devtmpfs ino15391 scontextu:r:shell:s0 tcontextu:object_r:hab_device:s0 tclasschr_file permissive0
07-18 17:48:44.691 6105 6114 I Adreno-GSL_RPC: gsl_rpc_connect:1211: connecting using conn_id 0
07-18 17:48:44.692 6105 6114 I uhab : habmm_socket_open: hab: open failed, error code 13 Permission denied
07-18 17:48:44.692 6105 6114 E Adreno-GSL_RPC: gsl_hab_open:51: Unable to habmm_socket_open err -13
后来修改
allow shell hab_device:chr_file_rw_file_perms; 2线程时序导致空指针异常
pid: 1082, tid: 1534, name: HwBinder:1082_1 /system/vendor/bin/ipacm
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
Cause: null pointer dereferencex0 0000000000000000 x1 0000000000000000 x2 6c206b636172746e x3 0a2e646165726874x4 2072656e65747369 x5 000000719b41d399 x6 20746f4720202928 x7 7364662068746f62x8 edf87d25729f7502 x9 edf87d25729f7502 x10 0000000000004001 x11 0000000000000000x12 656e657473696c20 x13 000000000000009a x14 0000000000000000 x15 000000719b98e3f8x16 000000719beb11e0 x17 000000719be44950 x18 0000000000000001 x19 0000000000000000x20 000000719b98f588 x21 0000000000000006 x22 000000719b98f588 x23 000000719b4327a8x24 000000719b48f000 x25 0000005fcc052680 x26 0000000000000000 x27 000000719b98f588x28 0000000000000000 x29 000000719b98e440sp 000000719b98e410 lr 0000005fcc052908 pc 0000005fcc0500c4backtrace:#00 pc 00000000000330c4 /vendor/bin/ipacm (IPACM_ConntrackListener::CreateConnTrackThreads()36)#01 pc 0000000000035904 /vendor/bin/ipacm (IPACM_OffloadManager::provideFd(int, unsigned int)644)#02 pc 000000000000a1d8 /vendor/lib64/liboffloadhal.so (HAL::setHandles(android::hardware::hidl_handle const, android::hardware::hidl_handle const, std::__1::functionvoid (bool, android::hardware::hidl_string const))420)#03 pc 000000000000ceec /system/lib64/vndk-28/android.hardware.tetheroffload.config1.0.so (android::hardware::tetheroffload::config::V1_0::BnHwOffloadConfig::_hidl_setHandles(android::hidl::base::V1_0::BnHwBase*, android::hardware::Parcel const, android::hardware::Parcel*, std::__1::functionvoid (android::hardware::Parcel))316)#04 pc 000000000000d1a0 /system/lib64/vndk-28/android.hardware.tetheroffload.config1.0.so (android::hardware::tetheroffload::config::V1_0::BnHwOffloadConfig::onTransact(unsigned int, android::hardware::Parcel const, android::hardware::Parcel*, unsigned int, std::__1::functionvoid (android::hardware::Parcel))320)#05 pc 000000000001d334 /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::executeCommand(int)640)#06 pc 000000000001430c /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::getAndExecuteCommand()196)#07 pc 0000000000014588 /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::joinThreadPool(bool)268)#08 pc 000000000001c1ac /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::PoolThread::threadLoop()24)#09 pc 000000000000fa08 /system/lib64/vndk-sp-28/libutils.so (android::Thread::_threadLoop(void*)280)#10 pc 00000000000819b4 /system/lib64/libc.so (__pthread_start(void*)36)#11 pc 0000000000023478 /system/lib64/libc.so (__start_thread68)
具体代码就不多贴了直接贴修改就懂了。 3libart 出现BUS_ADRALN
pid: 2147, tid: 2147, name: m.app.animation com.app.animation
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x656c62x0 0000006f90ee8648 x1 0000000041504e4d x2 0000007ff0cf5be8 x3 0000006f90668ed8x4 0000000012c12da6 x5 0000007ff0cf5c46 x6 6f00630015000000 x7 770067002e006d00x8 0000000000656c62 x9 0000006f90e4b700 x10 0000000000000032 x11 69006e0061002e00x12 6900740061006d00 x13 000000006e006f00 x14 0000000070ca1348 x15 0000000000003ebax16 0000006f90714140 x17 000000701265db30 x18 0000000000000000 x19 0000007ff0cf5be8x20 0000000041504e4d x21 0000006f90e2b6f8 x22 0000006f90e2b6f8 x23 0000007ff0cf6088x24 0000007ff0cf5c14 x25 00000070168895e0 x26 000000007090b600 x27 0000000071178cb0x28 0000000012c12c20 x29 0000007ff0cf5bd0sp 0000007ff0cf5bb0 lr 0000006f90558a30 pc 0000000000656c62backtrace:#00 pc 0000000000656c62 unknown#01 pc 0000000000473a2c /system/lib64/libart.so (art::RuntimeCallbacks::DdmPublishChunk(unsigned int, art::ArrayRefunsigned char const const)56)#02 pc 00000000003f0f14 /system/lib64/libart.so (art::DdmServer_nativeSendChunk(_JNIEnv*, _jclass*, int, _jbyteArray*, int, int)356)#03 pc 000000000007fb74 /system/framework/arm64/boot-core-libart.oat (offset 0x79000) (org.apache.harmony.dalvik.ddmc.DdmServer.nativeSendChunk196)#04 pc 000000000013e9bc /system/framework/arm64/boot-core-libart.oat (offset 0x79000) (org.apache.harmony.dalvik.ddmc.DdmServer.sendChunk76)#05 pc 00000000007e92ac /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.ddm.DdmHandleAppName.sendAPNM284)#06 pc 0000000000879a78 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread.handleBindApplication952)#07 pc 0000000000876034 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread$H.handleMessage6916)#08 pc 0000000000ab7724 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.os.Handler.dispatchMessage180)#09 pc 0000000000aba820 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.os.Looper.loop1264)#10 pc 0000000000882e28 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread.main664)#11 pc 0000000000554c4c /system/lib64/libart.so (art_quick_invoke_static_stub604)#12 pc 00000000000cf6e8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)232)#13 pc 000000000045c840 /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)104)#14 pc 000000000045e294 /system/lib64/libart.so (art::InvokeMethod(art::ScopedObjectAccessAlreadyRunnable const, _jobject*, _jobject*, _jobject*, unsigned long)1440)#15 pc 00000000003ee1d4 /system/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*)52)#16 pc 000000000011e6d4 /system/framework/arm64/boot-core-oj.oat (offset 0x114000) (java.lang.Class.getDeclaredMethodInternal [DEDUPED]180)#17 pc 0000000000bf1bd8 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run136)#18 pc 0000000000bf8dc0 /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (com.android.internal.os.ZygoteInit.main3088)#19 pc 0000000000554c4c /system/lib64/libart.so (art_quick_invoke_static_stub604)#20 pc 00000000000cf6e8 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)232)#21 pc 000000000045c840 /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)104)#22 pc 000000000045c4a0 /system/lib64/libart.so (art::InvokeWithVarArgs(art::ScopedObjectAccessAlreadyRunnable const, _jobject*, _jmethodID*, std::__va_list)424)#23 pc 0000000000361b60 /system/lib64/libart.so (art::JNI::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)652)#24 pc 00000000000b2374 /system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)120)#25 pc 00000000000b4cf8 /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vectorandroid::String8 const, bool)756)#26 pc 000000000000219c /system/bin/app_process64 (main1200)#27 pc 00000000000acac8 /system/lib64/libc.so (__libc_init88)
由于每次异常打印的异常地址都是 fault addr 0x656c62且多个应用都有打印说明该问题是libart.so强相关而不是com.app.animation的内存问题。地址0x656c62固定有可能两种情况一种是代码中存在字节不对齐情况一种是这个地址是相对于对象首地址的偏移地址这是对象被释放后的解引用。 出现的原因是adbd守护进程会因为开机阶段多次重新配置usb模式而被多次杀掉重新启动。如果杀掉重新启动adbd的时候正好碰上zygote孵化进程某些进程就有概率报告这个错误。
解决方法 Android12没有该问题。Android12上面gState与this_指针没有delete, 他们使用C17的std::optional模板无new与delete。 4system_server 调用 debug dump导致audio crash 五、其他
