精华内容
下载资源
问答
  • Tombstoned clusters

    2020-12-27 01:59:31
    <div><p>Great library, much quicker than the Google one. <p>Slight problem though - I'm adding ~16,000 markers relatively slowly while moving around the map, zooming etc. <p>After not very long ...
  • <div><p>If your application gets tombstoned whilst the qr code scanner is visible you get a crash in SimpleCameraReader.cs on line 147: _reader = this.Options.BuildMultiFormatReader() <p>as ...
  • <div><p>Issue originally raised as followup to https://github.com/couchbase/couchbase-lite-ios/issues/509. Crux of the issue is that tombstoned conflict branches are preserved during revision pruning...
  • <div><p>Per the tombstone notice: <p>This file is a placeholder to preserve links. Please remove after 3 months or the release of kubernetes 1.10, whichever comes first. <p>I'...
  • <div><p>This ensures all synchronized entities that are updated/deleted are added to the upcoming RevisionRecord so their changes are pushed to the remote. <p>Fix #446</p><p>该提问来源于开源项目ÿ...
  • <div><p>Hello, After updating to Sync Gateway 1.5 with convergence enabled in our dev environment. I am seeing so many errors mentioned in subject. <p>After checking client calls I could see this ...
  • I//system/bin/tombstoned: registered intercept for pid 32048 and type kDebuggerdJavaBacktrace 2020-07-15 15:45:11.938 32048-32059/com.pinupapp I/com.pinupapp: Thread[7,tid=32059,...
  • <div><p>First time I post on github, sorry in advance if I'...05-16 14:25:26.653 1107 1107 I /system/bin/tombstoned: found intercept fd 512 for pid 1338 and type kDebuggerdJavaBacktrace 05-...
  • ANR when starting app

    2020-12-26 02:40:48
    [tombstoned]' 2020-05-15 12:47:20.802 1012-1120/? E/ActivityManager: ANR in chat.delta PID: 17096 Reason: executing service chat.delta/org.thoughtcrime.securesms.connect.KeepAliveService Load: ...
  • I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 2019-05-23 15:43:40.611 819-819/? I//system/bin/tombstoned: received crash request for pid 25714 2019-05-23 15:43:40.613...
  • crash in mapbox

    2020-12-27 09:54:34
    I/crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone 2019-03-27 10:27:56.235 296-296/? I//system/bin/tombstoned: received crash request for pid 1587 2019-03-27 10:27:56.241 ...
  • I/crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone 12-07 11:48:13.611 1509-1509/? I//system/bin/tombstoned: received crash request for pid 21430 12-07 11:48:13.611 21621-...
  • I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 819-819/? I/tombstoned: received crash request for pid 11731 11762-11762/? I/crash_dump64: performing dump of process ...
  • 08-12 12:17:49.108 144 144 I /system/bin/tombstoned: received crash request for pid 5407 08-12 12:17:49.108 5430 5430 I crash_dump32: performing dump of process 5407 (target tid = 5425) 08-12 12:...
  • I/crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone 2020-12-01 12:56:59.808 1083-1083/? I//system/bin/tombstoned: received crash request for pid 3928 2020-12-01 12:56:59....
  • I//system/bin/tombstoned: received crash request for pid 8689 2019-07-04 14:19:11.838 10694-10694/? I/crash_dump64: performing dump of process 8689 (target tid = 10644) 2019-07-04 14:19:11.839 ...
  • I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 06-07 15:02:13.596 1813-1813/? I//system/bin/tombstoned: received crash request for pid 17562 06-07 15:02:13.597 17904-...
  • I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 2020-09-23 15:10:23.362 921-921/? I/tombstoned: received crash request for pid 10331 2020-09-23 15:10:23.363 10360-10360...
  • 07-25 11:48:14.676 14388 14388 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 07-25 11:48:14.676 840 840 I /system/bin/tombstoned: received crash request for pid 14363 ...
  • E//system/bin/tombstoned: Tombstone written to: /data/tombstones//tombstone_00 03-13 21:29:12.829 644-644/? E/lowmemorykiller: Error opening /proc/947/oom_score_adj; errno=2 03-13 21:29:12.831 ...
  • <h3>Versions <ul><li>Python: 3.7.1</li><li>OS: Android 8.1.0</li><li>Buildozer: 0.39</li></ul> <h3>Description <p>I am trying to use the numpy fft for real input in an android app....
  • <div><p>When I try to scan to build my library, Droidsound-E Crashes. I have tried clearing cache + storage, and uninstalling and reinstalling. <p>08-11 10:42:18.226 1069 26017 I ActivityManager:...
  • t seem like the tombstoned outcome in <code>updateOutcomesLeavingTombstone</code>: <pre><code>swift currentOutcomes.forEach { $0.deletedDate = Date() $0.values = Set() } </code></pre> <p>...
  • 问题 用logcat抓取到报错如下 10-26 15:14:46.777 3174 3174 I crash_dump32: obtaining output fd from tombstoned, type: ...10-26 15:14:46.778 1810 1810 I /system/bin/tombstoned: received cr...

     问题

    用logcat抓取到报错如下

    10-26 15:14:46.777  3174  3174 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
    10-26 15:14:46.778  1810  1810 I /system/bin/tombstoned: received crash request for pid 3152
    10-26 15:14:46.779  3174  3174 I crash_dump32: performing dump of process 3152 (target tid = 3152)
    10-26 15:14:46.779  3174  3174 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    10-26 15:14:46.780  3174  3174 F DEBUG   : Build fingerprint: 'Allwinner/virgo_perf1/virgo-perf1:8.1.0/OPM1.171019.026/20191026-150808:userdebug/test-keys'
    10-26 15:14:46.780  3174  3174 F DEBUG   : Revision: '0'
    10-26 15:14:46.780  3174  3174 F DEBUG   : ABI: 'arm'
    10-26 15:14:46.780  3174  3174 F DEBUG   : pid: 3152, tid: 3152, name: r.handwritedemo  >>> com.softwinner.handwritedemo <<<
    10-26 15:14:46.780  3174  3174 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x906e7573
    10-26 15:14:46.780  3174  3174 F DEBUG   :     r0 906e7573  r1 906e7573  r2 00000010  r3 00000005
    10-26 15:14:46.780  3174  3174 F DEBUG   :     r4 906e7573  r5 00000073  r6 be86e8bc  r7 ffffffff
    10-26 15:14:46.780  3174  3174 F DEBUG   :     r8 00000000  r9 ffffffff  sl 00000014  fp ad133dce
    10-26 15:14:46.780  3174  3174 F DEBUG   :     ip 80000000  sp be86e818  lr adc4c00f  pc adc27fc2  cpsr 80070030
    10-26 15:14:46.688  3152  3152 I r.handwritedemo: type=1400 audit(0.0:47): avc: denied { open } for path="/dev/input" dev="tmpfs" ino=8987 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:input_device:s0 tclass=dir permissive=1
    10-26 15:14:46.688  3152  3152 I r.handwritedemo: type=1400 audit(0.0:48): avc: denied { read write } for name="event4" dev="tmpfs" ino=1762 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=1
    10-26 15:14:46.688  3152  3152 I r.handwritedemo: type=1400 audit(0.0:49): avc: denied { open } for path="/dev/input/event4" dev="tmpfs" ino=1762 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=1
    10-26 15:14:46.688  3152  3152 I r.handwritedemo: type=1400 audit(0.0:50): avc: denied { ioctl } for path="/dev/input/event4" dev="tmpfs" ino=1762 ioctlcmd=0x4506 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=1
    10-26 15:14:47.214  3174  3174 F DEBUG   : 
    10-26 15:14:47.214  3174  3174 F DEBUG   : backtrace:
    10-26 15:14:47.214  3174  3174 F DEBUG   :     #00 pc 00019fc2  /system/lib/libc.so (strlen+21)
    10-26 15:14:47.214  3174  3174 F DEBUG   :     #01 pc 0003e00b  /system/lib/libc.so (__vfprintf+3754)
    10-26 15:14:47.214  3174  3174 F DEBUG   :     #02 pc 00052755  /system/lib/libc.so (vsnprintf+128)
    10-26 15:14:47.214  3174  3174 F DEBUG   :     #03 pc 00006483  /system/lib/liblog.so (__android_log_print+54)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #04 pc 00004cad  /system/lib/libhandwritten.so (input_reader_init(void*)+224)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #05 pc 000046c9  /system/lib/libhandwritten.so (android::HandWriteHandler::start()+228)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #06 pc 000a118b  /system/lib/libandroid_runtime.so (android::nativeHandwrittenStart(_JNIEnv*, _jobject*, long long, _jobject*, _jobject*, _jobject*, _jobject*, int, int, int, int)+622)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #07 pc 007dde4d  /system/framework/arm/boot-framework.oat (offset 0x2f2000) (android.view.Surface.nativeHandwrittenStart+220)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #08 pc 00408375  /system/lib/libart.so (art_quick_invoke_stub_internal+68)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #09 pc 0040d4e7  /system/lib/libart.so (art_quick_invoke_stub+230)
    10-26 15:14:47.215  3174  3174 F DEBUG   :     #10 pc 000b00b7  /system/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+138)
    

    不像JAVA层的代码那样,告诉你哪一行报了什么错,如何去查呢?

    解决步骤
    1.从logcat中可以到初步报错信息

    10-26 15:14:47.215  3174  3174 F DEBUG   :     #04 pc 00004cad  /system/lib/libhandwritten.so (input_reader_init(void*)+224)

    这行报错信息,正是我改动的代码所编译出来的库,报错信息还说了是哪个函数(input_reader_init),但是224不是行数

    2.找到libhandwritten.so

    路径:out/target/product/virgo-perf1/symbols/system/lib/libhandwritten.so

    3.把libhandwritten.so拷贝到prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin下面去,这个路径含有一个名字含有addr2line的工具

    4.执行./arm-eabi-addr2line -Cfe libhandwritten.so 0x00004cad,注意最后一个参数对应log中的,然后得到结果

    epoll_register_all_input(int, char const*)
    frameworks/base/libs/handwritten/InputReader.cpp:117
    

    报错在frameworks/base/libs/handwritten/InputReader.cpp的117行

    展开全文
  • t yet been tombstoned. <p>Example. <pre><code> set.Add("key", 1) #produces delta with ID: Qa set.Add("key", 2) #produces delta with ID: Qb set.Rmv("key") # produces delta ...
  • 出现NE问题的原因有很多,如空指针、内存踩踏、FDLEAK、数组越界访问等在出现问题时,Kernel会发送一个signal给user space,user space中有个tombstoned进程接收处理信号,在异常进程奔溃前,tombstoned会将该进程的...

    简介

    NE即Native Exception,我们主要指Android C/C++程序出现异常报错,因Camera HAL是由C/C++实现的,在相机系统开发过程中,经常会碰到NE问题。出现NE问题的原因有很多,如空指针、内存踩踏、FDLEAK、数组越界访问等在出现问题时,Kernel会发送一个signal给user space,user space中有个tombstoned进程接收处理信号,在异常进程奔溃前,tombstoned会将该进程的backtrace、memroy map等信息抓取出来保存到/data/tombstones/tombstone_xx文件、同时会将tombstone信息输出到logcat中。在一些平台,经过设置后,可将整个崩溃进程保存为coredump文件,可通过Trace32或者GDB调试coredump文件。

    本文主要介绍Native栈还原,即根据NE报错信息,定位到报错代码,使用的工具是addr2line
    注意:内存踩踏出现的报错通常报错位置可能不是出错位置,所以踩内存问题通常需要借助工具定位

    Native栈还原

    1. 我们抓到NE报错问题后首先将tombstone文件从/data/tombstones/tombstone_xx导出,如:

      *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
      Build fingerprint: 'XXXX/XX/XX:10/QKQ1.200412.002/eng.buildf.20200611.122340:user/release-keys'
      Revision: '0'
      ABI: 'arm64'
      Timestamp: 2020-06-13 11:18:11+0800
      pid: 13260, tid: 13260, name: provider@2.4-se  >>> /vendor/bin/hw/android.hardware.camera.provider@2.4-service_64 <<<
      uid: 1047
      signal 6 (SIGABRT), code 0 (SI_USER from pid 4396, uid 0), fault addr --------
          x0  0000007157fd7b20  x1  0000000000000089  x2  00000000fffffffe  x3  0000000000000000
          x4  0000000000000000  x5  00000000ffffffff  x6  00000000ffffffff  x7  000000716d685000
          x8  0000000000000062  x9  0000000000000089  x10 0000000000000009  x11 0000000000000000
          x12 000000716cf54b47  x13 000000716ceec98d  x14 0000000000000000  x15 0000000000050482
          x16 00000071f170a950  x17 00000071f1695320  x18 00000071634af530  x19 00000000fffffffe
          x20 0000000000000000  x21 0000007157fd7b20  x22 0000000000000089  x23 00000071f30a2188
          x24 00000071f1db9020  x25 0000000000000002  x26 000000716d686000  x27 00000071580092c8
          x28 0000000000000002  x29 0000007ff862f280
          sp  0000007ff862f220  lr  00000071f16988ac  pc  00000071f169533c
      
      backtrace:
            #00 pc 000000000008033c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: 778f9db29d872fa660c03bee8d69f746)
            #01 pc 00000000000838a8  /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+140) (BuildId: 778f9db29d872fa660c03bee8d69f746)
            #02 pc 00000000000e7a98  /apex/com.android.runtime/lib64/bionic/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+596) (BuildId: 778f9db29d872fa660c03bee8d69f746)
            #03 pc 000000000058d444  /vendor/lib64/hw/camera.qcom.so (CamX::Mutex::Lock()+116) (BuildId: f3ec37ddca55cd2b52366606c94f3e2a)
            #04 pc 00000000007614fc  /vendor/lib64/hw/camera.qcom.so (CamX::Session::Destroy()+572) (BuildId: f3ec37ddca55cd2b52366606c94f3e2a)
            #05 pc 00000000006ae9a8  /vendor/lib64/hw/camera.qcom.so (CamX::ChiContext::DestroySession(CamX::CHISession*)+40) (BuildId: f3ec37ddca55cd2b52366606c94f3e2a)
            #06 pc 000000000017341c  /vendor/lib64/hw/com.qti.chi.override.so (Session::Destroy(int)+84) (BuildId: ec7b9034d259422289af1a300c889c42)
            #07 pc 00000000001b606c  /vendor/lib64/hw/com.qti.chi.override.so (UsecaseMultiCamera::Destroy(int)+1660) (BuildId: ec7b9034d259422289af1a300c889c42)
            #08 pc 0000000000173e64  /vendor/lib64/hw/com.qti.chi.override.so (Usecase::DestroyObject(int)+732) (BuildId: ec7b9034d259422289af1a300c889c42)
            #09 pc 0000000000157a34  /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::TeardownOverrideUsecase(camera3_device const*, int)+628) (BuildId: ec7b9034d259422289af1a300c889c42)
            #10 pc 0000000000156f0c  /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::TeardownOverrideSession(camera3_device const*, unsigned long, void*)+724) (BuildId: ec7b9034d259422289af1a300c889c42)
            #11 pc 000000000030dae8  /vendor/lib64/hw/camera.qcom.so (CamX::HALDevice::Close()+960) (BuildId: f3ec37ddca55cd2b52366606c94f3e2a)
            #12 pc 00000000003013d0  /vendor/lib64/hw/camera.qcom.so (CamX::close(hw_device_t*)+3928) (BuildId: f3ec37ddca55cd2b52366606c94f3e2a)
            #13 pc 0000000000305e60  /vendor/lib64/hw/camera.qcom.so (CamX::close(hw_device_t*)+336) (BuildId: f3ec37ddca55cd2b52366606c94f3e2a)
            #14 pc 000000000002d888  /vendor/lib64/camera.device@3.2-impl.so (android::hardware::camera::device::V3_2::implementation::CameraDeviceSession::close()+248) (BuildId: 53ae9500ac4e483bad90ffa7a69dfc)
      
    2. 根据tombstone文件中的版本信息、报错堆栈找到带调试信息的so (通常在同次编译的symbols目录,如out/target/product/K81950AA1/symbols/),根据信号量signal值初步判断出错的类型,怎么确定so带调试信息?

      在Linux中,可通过file命令读取信息,如果输出显示not stripped表示带调试信息
      
      file out/target/product/K81950AA1/symbols/vendor/lib64/hw/com.qti.chi.override.so
      
      out/target/product/K81950AA1/symbols/vendor/lib64/hw/com.qti.chi.override.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[md5/uuid]=4e4e59619ceda634c1cd826fd2717bd8, not stripped
      

    ​ 常见的signal含义:

    ​ SIGABRT 6 由abort(3)发出的退出指令,一般是代码逻辑走到了abort函数

    ​ SIGSEGV 11 无效的内存引用,段错误、内存问题、空指针等

    ​ 其他信号含义参考Linux信号列表及其详解

    1. 上面的backtrace中,显示的pc地址是相对地址(相对于so map的地址)可直接用addr2line来解析,如第5帧(#05 pc 00000000006ae9a8 /vendor/lib64/hw/camera.qcom.so),有时pc地址是绝对地址,我们怎么通过绝对地址来计算相对地址呢?(下面例子和上面backtrace不是同一个)

      #0 pc 7591fab52c
      #1 pc 750f5a2044
      #2 pc 750f881e08
      #3 pc 750f884f40
      #4 pc 750f9e0c50
      #5 pc 750fa072bc
      
      Dump native maps files (tombstone文件一般包含,也可在进程奔溃前通过**adb shell cat /proc/$pid/maps**获得),根据pc值可知是落在libart.so:
      750f4e0000-750fada000 r-xp    /system/lib64/libart.so
      正常的so文件默认都是加载到0地址的,但libart.so是加载到其他地址的,不同的platform加载地址可能不同,具体可以用readelf证实。readelf放在目录prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.X/bin下面,使用命令 arm-linux-androideabi-readelf -a -W libart.so:
      Program Headers:
      Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
      PHDR 0x000040 0x0000000000027040 0x0000000000027040 0x0001c0 0x0001c0 R 0x8
      LOAD 0x000000 0x0000000000027000 0x0000000000027000 0x5eaf64 0x5eaf64 R E 0x1000
      LOAD 0x5eb270 0x0000000000613270 0x0000000000613270 0x013318 0x016438 RW 0x1000
      可以看到第1个LOAD加载到了0x27000,即libart.so的加载地址是0x27000
      
      计算相对地址
      相对地址 = pc - maps 起始地址 + so加载地址
      例如上面的例子,libart.so加载地址是0x27000,则计算#1 pc 750f5a2044的公式是750f5a2044 - 750f4e0000 + 0x27000 = 0xE9044
      
    2. 解析地址(addr2line分32bit和64bit,根据要解析的库的abi来选择)

       prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line -Cfe out/target/product/K81950AA1/symbols/vendor/lib64/hw/camera.qcom.so 00000000006ae9a8 
      

    调试技巧

    在进程卡住的时候,比如相机黑屏卡住,我们在调试的时候经常通过adb shell kill -6 $PID 来主动杀进程,获取tombstone信息,也可以通过adb shell debuggerd -b $PID获得。

    在杀进程前,最好能先收集进程的memory、fd等信息,附带一个脚本:

    #!/bin/sh
    
    logpath=$1
    
    if [ -z "$logpath" ]  
    then  
        logpath=$(pwd)"/MemoryDebug"
        echo $(pwd)
    fi  
    
    adb root
    adb wait-for-device
    #need close selinux, others dump failure
    adb shell setenforce 0
    
    pid=`adb shell pidof android.hardware.camera.provider@2.4-service_64`
    echo "dump pid = "${pid}
    
    time=$logpath"/pid"${pid}"_"$(date +%Y%m%d%H%M%S)
    echo "log path: "$time
    mkdir -p ${time}
    
    #get maps and smaps info
    adb shell cat /proc/$pid/maps > $time/maps.txt
    adb shell cat /proc/$pid/smaps > $time/smaps.txt
    adb shell "pidof android.hardware.camera.provider@2.4-service_64 | xargs pmap -x" > $time/pmap.txt
    
    #get process fd info
    adb shell ls -a -l /proc/$pid/fd > $time/fd.txt
    
    #get all process info before dump
    adb shell ps -AT > $time/all_processinfo.txt
    
    #get process file state (thread info)
    adb shell lsof -p $pid > $time/$pid"_process_state.txt"
    
    #get current meminfo before dump
    adb shell dumpsys meminfo $pid > $time/$pid"_meminfo.txt"
    
    #dumpsys media.camera
    adb shell dumpsys media.camera > $time/media.camera.txt
    
    展开全文
  • Fix WP8

    2020-11-24 19:05:05
    <div><p>Force the focus of the camera Fix the plugin when the back button is pressed Fix the plugin when the app is tombstoned</p><p>该提问来源于开源项目:wildabeast/BarcodeScanner</p></div>
  • Tombstoned libdebuggerd_handler crash_dump 进程关系 Pipe 管道 进程通讯关系 debuggerd Android P上Java Crash、Native Crash的异常处理流程学习 Linux 信号 深入分析Android native exception框架 ...

    目录

     

    深入分析Android native exception框架

    MTK NE异常流程图

    Ptrace

    模块组成

    Tombstoned

    libdebuggerd_handler

    crash_dump

    进程关系

    Pipe 管道

    进程通讯关系

    debuggerd

    Android P上Java Crash、Native Crash的异常处理流程学习

    Linux 信号


    深入分析Android native exception框架

    参考MTK网站

    https://online.mediatek.com/QuickStart/fc6dd989-890d-444d-b4bf-13a93219702d

    参考博客

    https://blog.csdn.net/hl09083253cy/article/details/78927104?utm_source=blogxgwz0

    https://www.jianshu.com/p/110ea9bd2e3f

    https://www2.lauterbach.com/pdf/rtos_linux_stop.pdf

     

    MTK NE异常流程图(Q 之前)

    异常发送后,会执行到Arm_notify_die ,用户模式则执行force_sig_info 发送对应信号给用户进程,svc 模式就直接die(),重启手机。

     

    Ptrace

    https://www.cnblogs.com/tangr206/articles/3094358.html

     

     

     

    模块组成

    NE常见类型

    如空指针,非法指针,程序跑飞,内存踩坏,段地址错误等

    这类问题会被MMU 捕获,MMU 就会发送abort 信号给到cpu,这个时候cpu 根据信号类型执行对应的向量表函数,同时也由用户态切换到内核态,内存处理完会调用__send_signal()发送信号,debuggerd_init()里注册的函数debugger_signal_handler()会接收到信号

     

    一般native 应用都会动态链接一些库如libc.so/libutils.so,这些库动态加载是通过linker 完成的。Kernel 将native 应用、linker 加载到应用进程空间,先跑linker,再跑应用。

    linker执行期间还做了一件事:注册信号,具体的函数调用流程如下:
    __linker_init() -> __linker_init_post_relocation() -> debuggerd_init()

    system\core\debuggerd\tombstoned

     

    Tombstoned :

            "tombstoned/intercept_manager.cpp",

            "tombstoned/tombstoned.cpp"

             libdebuggerd、libevent

            "tombstoned/tombstoned.rc

    Debuggerd:

            Debuggerd.cpp

            libdebuggerd_client

    crash_dump

           crash_dump.cpp

           libtombstoned_client

    libdebuggerd_client

           client/debuggerd_client.cpp

    libdebuggerd_handler (need by linker)

           handler/debuggerd_handler.cpp

    libtombstoned_client

           tombstoned/tombstoned_client.cpp

    libdebuggerd

            "libdebuggerd/backtrace.cpp",

            "libdebuggerd/gwp_asan.cpp",

            "libdebuggerd/open_files_list.cpp",

            "libdebuggerd/tombstone.cpp",

     

    tombstoned

    Tombstoned :

            "tombstoned/intercept_manager.cpp",

            "tombstoned/tombstoned.cpp"

             libdebuggerd、libevent

            "tombstoned/tombstoned.rc

     

     

    bionic/libc/platform/bionic/reserved_signals.h

    #define BIONIC_SIGNAL_DEBUGGER (__SIGRTMIN + 3)

     

     

    Tombstoned

    tombstoned.cpp

    注册tombstone 自己的信号处理函数

     

     

    tombstone 建立监听回调处理函数,当客户端发起connect ,socket accept 就会触发对应事件,执行回调。intercept_socket 用于debuggerd 向 tombstoned 请求输出 tombstone,其中backtrace 通过debuggerd 输出。

    crash_socket 用于发生NE 时,内核发送信号,程序收到信息进入其注册的异常处理信号函数,在这里面最后会通过crash_socket连接到tombstoned 打印tombstone 

    这里tombstoned 自己发生异常,则直接执行_exit(1)

     

    Libevent之evconnlistener

    https://blog.csdn.net/u010710458/article/details/80067676

    https://blog.csdn.net/bestone0213/article/details/46729247

    bind()将端口跟socket 关联起来,listen()则成为服务端进入监听,accept()则当客户端有connect 则响应。

    accept()接到连接则执行客户端注册的回调。

     

    第一个参数是event_base,也就底层在监听套接字上有新的 TCP 连接

    第二个参数是accept()时执行回调,第三个参数是传递给回调的参数

     

    回调函数中,event_new 创建一个新的event加入监听

    第三个参数是事件触发类型

    第四个参数是事件触发回调函数

    第二个参数、第三个参数、第四个参数都是传递给crash_request_cb 的

    从socket 中读取请求数据,判断dump 类型及pid

    1. 判读如果是java dump 就,通过for_anrs 创建CrashQuere,其它类型通过for_tombstone创建CrashQueue,这里指定了日志保存目录,最大日志数,及最大并行处理数。
    2. anr 保存/data/anr ,最大日志64,最大并行4,tombstone 保存/data/tombstone,最大日志32,最大并行1。
    3. 如果当前正在处理dump 达到最大并行数,则将当前请求加入CrashQueue队尾,否则执行dump。
    4. 执行dump

     

    libdebuggerd_handler

        handler/debuggerd_handler.cpp

     

    bionic/linker/linker_main.cpp

     

    int sigaction(int signum, const struct sigaction *act,

    struct sigaction *oldact);

    signum参数指出要捕获的信号类型,act参数指定新的信号处理方式,oldact参数输出先前信号的处理方式(如果不为NULL的话)。

    struct sigaction结构体介绍


    struct sigaction {

    void (*sa_handler)(int);//信号处理函数

    void (*sa_sigaction)(int, siginfo_t *, void *);

    sigset_t sa_mask;

    int sa_flags;

    void (*sa_restorer)(void);

    }

     

    sa_handler 是一个函数指针,其含义与 signal 函数中的信号处理函数类似。或者设置为SIG_IGN忽略信号。

    sa_sigaction 则是另一个信号处理函数,它有三个参数,可以获得关于信号的更详细的信息。

    sa_flags 成员的值包含了 SA_SIGINFO 标志时,系统将使用 sa_sigaction 函数作为信号处理函数,否则使用 sa_handler 作为信号处理函数。在某些系统中,成员 sa_handler 与 sa_sigaction 被放在联合体中,因此使用时不要同时设置。
    sa_mask 成员用来指定在信号处理函数执行期间需要被屏蔽的信号,特别是当某个信号被处理时,它自身会被自动放入进程的信号掩码,因此在信号处理函数执行期间这个信号不会再度发生。

     

    sa_flags中包含了许多标志位,一个比较重要的标志位是SA_SIGINFO,当设定了该标志位时,表示信号附带的参数可以被传递到信号处理函数中,因此,应该为sigaction结构中的sa_sigaction指定处理函数,而不应该为sa_handler指定信号处理函数,否则,设置该标志变得毫无意义。即使为sa_sigaction指定了信号处理函数,如果不设置SA_SIGINFO,信号处理函数同样不能得到信号传递过来的数据,在信号处理函数中对这些信息的访问都将导致段错误(Segmentation fault)

     

    https://blog.csdn.net/q1007729991/article/details/53893743

     

    Ptrace

    https://www.cnblogs.com/tangr206/articles/3094358.html

    debuggerd_signal_handler

     

    创建子线程

     

    clone返回创建进程的进程ID,出错的话返回-1;

    CLONE_PARENT   创建的子进程的父进程是调用者的父进程,新进程与创建它的进程成了“兄弟”而不是“父子”

     CLONE_FS           子进程与父进程共享相同的文件系统,包括root、当前目录、umask

     CLONE_FILES      子进程与父进程共享相同的文件描述符(file descriptor)表

     CLONE_NEWNS   在新的namespace启动子进程,namespace描述了进程的文件hierarchy

     CLONE_SIGHAND   子进程与父进程共享相同的信号处理(signal handler)表

     CLONE_PTRACE   若父进程被trace,子进程也被trace

     CLONE_VFORK     父进程被挂起,直至子进程释放虚拟内存资源

     CLONE_VM           子进程与父进程运行于相同的内存空间

     CLONE_PID          子进程在创建时PID与父进程一致

     CLONE_THREAD    Linux 2.4中增加以支持POSIX线程标准,子进程与父进程共享相同的线程群

     

     

    CLONE_THREAD :将子进程加入父进程线程组,否则设置新的线程组

    CLONE_SIGHAND:信号处理函数跟父进程一样

    如果设置了CLONE_PARENT_SETTID,内核会将子进程的线程ID写入ptid所指向的位置。如果设置了CLONE_CHILD_SETTID,那么clone()会将子线程的线程ID写入指针ctid所指向的位置。如果设置了CLONE_CHILD_CLEARTID,则会在子进程终止时将ctid所指向的内存清零。

     

    等待子线程开始和结束

     

     

     

     

    debuggerd_dispatch_pseudothread

    int dup(int oldfd);等效fcntl(oldfd, F_DUPFD, 0)

    Dup 用于复制oldfd 所执行的文件描述符,若成功则返回尚未使用的最小的文件描述符。新文件描述符跟oldfd 指向同一文件;

    int dup2(int oldfd, int newfd);等效close(oldfd);fcntl(oldfd, F_DUPFD, newfd);

    使用newfd 文件描述符指定oldfd ;若newfd 已经存在,则关闭newfd 指向文件;若newfd 跟oldfd 相等,则返回newfd,不关闭newfd 指向文件

    创建读写管道

    子线程中设置输出输入文件描述符;

    main_tid 是发生crash 的进程,pseudothread_tid是clone 创建的线程,通过exccle 执行crash_dump。

    AEE产生流程图:

     

     

    crash_dump

          crash_dump.cpp

           libtombstoned_client

    将信号处理函数设置为默认,信号屏蔽掩码设置为空(这样阻塞时不会丢弃信号),设置sigpipe 处理函数

    让进程摆脱原会话的控制

    让进程摆脱原进程组的控制

    让进程摆脱原控制终端的控制

    setsid函数的进程成为新的会话的领头进程

     

    创建子线程,父进程通过pipe 读子进程,进入等待;

     

    解析execle 传递的参数,g_target_thread 是发生异常进程,pseudothread_tid是clone 出来的线程。

     

    获取进程名,/proc/pid/cmdline,线程名,/proc/pid/comm,/proc/self/comm

    获取进程的文件句柄,/proc/pid/fd 下文件句柄

    获取进程组中的线程

    ptrace()系统调用函数提供了一个进程(the “tracer”)监察和控制另一个进程(the “tracee”)的方法,并且可以检查和改变“tracee”进程的内存和寄存器里的数据,它可以用来实现断点调试和系统调用跟踪。

    其基本原理是: 当使用了ptrace跟踪后,所有发送给被跟踪的子进程的信号(除了SIGKILL),都会被转发给父进程,而子进程则会被阻塞,这时子进程的状态就会被系统标注为TASK_TRACED,而父进程通过waitpid(wstatus)(或者其它wait系统调用)被通知收到信号后,就可以对停止下来的子进程进行检查和修改,然后让子进程继续运行。当被跟踪后,每当系统调用信号量传来,甚至信号量会被忽略时,tracee会暂停,被跟踪的程序在进入或者退出某次系统调用的时候都会触发一个SIGTRAP信号。

     

    PTRACE_O_TRACECLONE:被跟踪进程在下一次调用clone()时将其停止,并自动跟踪新产生的进程。这样wait_for_vm_process 可以通过PTRACE_GETEVENTMSG获取clone 产生的新进程。

    新产生的进程开始执行时就已设置SIGSTOP信号,新产生的进程刚执行就收到SIGSTOP信号,wait_for_vm_process 会等待新的进程停止信号SIGSTOP,检测是否是SIGSTOP信号,并ptrace(PTRACE_CONT, child, 0, 0)让clone 的子进程继续运行;

    这时pseudothread_tid进程调用create_vm_process,会调用clone 创建子进程,被跟踪,子进程执行就发送SIGSTOP停止,这时wait_for_clone 获取到子进程pid,并让子进程继续执行,子进程执行时会再次调用clone 创建孙进程,从而获取到孙进程pid,重复上面流程。

     

    crash_dump 通过socket connect 到tombstoned_client,tombstone_client 与socket 服务端tombstoned 通讯。

    这里g_output_fd 就是这次socket 请求端(crash_dump 中fork 的子进程)发送数据文件句柄,engrave_tombstone 将dump的信息通过g_output_fd 发送给tombstoned。

     

    连接tombstoned后,crash_dump端会通过g_output_fd将要写入的日志内容发送给tombstoned,tombstoned最终存在文件中。

     

    这里tombstone_path 是/proc/%d/task/%d/fd/%d 文件句柄对应的链接,即g_output_fd文件句柄对应链接,这里通知aee_aed。aee_aed 就是libaed.so 中crash_mini_dump_notify 方法来获取mini dump信息。

     

     

    aee_aed每次会创建同名子进程,子进程创建aee_dumpstate。

    aee_aed 抓取相应日志与打包,aee_dumpstate获取/proc/$pid 下文件。

    根据/proc/sys/kernel/core_pattern  启动aee_core_forwarder 获取coredump,跟aee_aed 一起打包为db.

     

    init->aee_aed64->【(aee_aed64与父进程同名->aee_dumpstate)】

    init->aee_aedv64->aee_aedv64->aee_dumpstatev

    2->aee_core_forwarder   coredump

     

    通知system_server。

    进程关系

    • 在debuggerd_signal_handler 中是发生crash 的线程,gettid 为进程id,getpid 是组进程id,不同,是父子关系。

     

    1、debuggerd_signal_handler 中clone进程pseudothread

    clone(debuggerd_dispatch_pseudothread, pseudothread_stack,

              CLONE_THREAD | CLONE_SIGHAND | CLONE_VM | CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID,

    getpid 与debuggerd_signal_handler 中一样,gettid 不同于进程debuggerd_signal_handler 中;但是打印的log,pid:tid 跟发生问题debuggerd_signal_handler 中一样。

     

    2、create_vm_process 中

    clone(nullptr, nullptr, CLONE_FILES, nullptr)

     

    • pseudothread中__fork()进程,在子进程中执行crash_dump

    execle(CRASH_DUMP_PATH

     

    在父进程中(__fork()进程)getid跟getpid一样,getppid跟debuggerd_signal_handler 中getpid 一样,在crash_dump中跟父进程中(__fork()进程)一样

     

    • crash_dump 调用setSid 前

     

    调用setSid后gettid、getpid、getppid 一样

     

    fork 创建子进程,在子进程中 gettid跟getpid 一样,getppid 为crash_dump

     

    • debuggerd_signal_handler 中create_vm_process与crash_dump 通过fork 创建的子进程中wait_for_vm_process(pseudothread_tid)

     

    Pipe 管道

    管道也是unix ipc的最老形式,管道有两种限制

    数据自己读不能自己写

    它们是半双工的。数据只能在一个方向上流动。

    数据一旦被读走,便不在管道中存在,不可反复读取

    它们只能在具有公共祖先的进程之间使用。通常,一个管道由一个进程创建,然后该进程调用fork,此后父、子进程之间就可应用该管道。

     

    管道由pipe函数创建而成pipe(pipe_fd)经由参数pipe_fd返回两个文件描述符,pipe_fd[0]为读而打开,pipe_fd[1]为写而打开。pipe_fd[1]的输出是pipe_fd[0]的输入。

    函数调用成功返回r/w两个文件描述符。无需open,但需手动close。规定:fd[0] → r; fd[1] → w,就像0对应标准输入,1对应标准输出一样。向管道文件读写数据其实是在读写内核缓冲区。管道创建成功以后,创建该管道的进程(父进程)同时掌握着管道的读端和写端。

     

     

     

    父进程写,子进程读流程:

    父进程调用pipe函数创建管道,得到两个文件描述符fd[0]、fd[1]指向管道的读端和写端。

    父进程调用fork创建子进程,那么子进程也有两个文件描述符指向同一管道。

    父进程关闭管道读端,子进程关闭管道写端。父进程可以向管道中写入数据,子进程将管道中的数据读出。由于管道是利用环形队列实现的,数据从写端流入管道,从读端流出,这样就实现了进程间通信。

     

    管道读写4中情况

    如果所有指向管道写端的文件描述符都关闭了(管道写端引用计数为0),而仍然有进程从管道的读端读数据,那么管道中剩余的数据都被读取后,再次read会返回0,就像读到文件末尾一样。

    如果有指向管道写端的文件描述符没关闭(管道写端引用计数大于0),而持有管道写端的进程也没有向管道中写数据,这时有进程从管道读端读数据,那么管道中剩余的数据都被读取后,再次read会阻塞,直到管道中有数据可读了才读取数据并返回。

    如果所有指向管道读端的文件描述符都关闭了(管道读端引用计数为0),这时有进程向管道的写端write,那么该进程会收到信号SIGPIPE,通常会导致进程异常终止。当然也可以对SIGPIPE信号实施捕捉,不终止进程。具体方法信号章节详细介绍。

    如果有指向管道读端的文件描述符没关闭(管道读端引用计数大于0),而持有管道读端的进程也没有从管道中读数据,这时有进程向管道写端写数据,那么在管道被写满时再次write会阻塞,直到管道中有空位置了才写入数据并返回。

     

    进程通讯关系

    debuggerd_handler.cpp

    static void debuggerd_signal_handler(int signal_number, siginfo_t* info, void* context) {

    。。。。

    <!--这里通过clone 创建伪进程

    pid_t child_pid =

        clone(debuggerd_dispatch_pseudothread, pseudothread_stack,

              CLONE_THREAD | CLONE_SIGHAND | CLONE_VM | CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID,

              &thread_info, nullptr, nullptr, &thread_info.pseudothread_tid);

    。。。。

    <!--等待伪进程开始执行,这个时候为clone 创建进程ctid 不等于-1;

    futex_wait(&thread_info.pseudothread_tid, -1);

    <!--等待伪进程结束,进程结束时对应ctid(thread_info.pseudothread_tid,)会被清空;

    futex_wait(&thread_info.pseudothread_tid, child_pid);

     

    <!--再次发送从而执行默认信号处理函数,产生coredump

    resend_signal(info);

    }

     

    static int debuggerd_dispatch_pseudothread(void* arg) {

    。。。。

    <!--创建两对pipe ,用于通讯

    if (!Pipe(&input_read, &input_write) != 0 || !Pipe(&output_read, &output_write)) {

        fatal_errno("failed to create pipe");

      }

    <!--pseudothread进程output_write 用于写,input_read用于读

    <!--子进程input_write用于写,output_read用于读

    ssize_t rc = TEMP_FAILURE_RETRY(writev(output_write.get(), iovs, arraysize(iovs)));

     

    pid_t crash_dump_pid = __fork();

     

      if (crash_dump_pid == -1) {

      } else if (crash_dump_pid == 0) {

        <!-- 子进程与其stdin/stdout关联,这样execle就可以访问,关闭两对pipe.

       TEMP_FAILURE_RETRY(dup2(input_write.get(), STDOUT_FILENO));

        TEMP_FAILURE_RETRY(dup2(output_read.get(), STDIN_FILENO));

        input_read.reset();

        input_write.reset();

        output_read.reset();

    output_write.reset();

    <!--子进程执行crash_dump,不会返回

    execle(CRASH_DUMP_PATH, CRASH_DUMP_NAME, main_tid, pseudothread_tid, debuggerd_dump_type,

               nullptr, nullptr);

    return 1;

      }

     

    <!--pseudothread进程关闭对应端pipe

     input_write.reset();

     output_read.reset();

    <!--pseudothread进程读进入等待

    rc = TEMP_FAILURE_RETRY(read(input_read.get(), &buf, sizeof(buf)));

     

    create_vm_process();

     

    <!--等待子进程crash_dump退出

     if (TEMP_FAILURE_RETRY(waitpid(crash_dump_pid, &status, 0)) == -1)

    <!--等待crash_dump 通过fork 的子进程结束,这样对端管道关闭,pseudothread读返回

    TEMP_FAILURE_RETRY(read(input_read, &buf, sizeof(buf)));

     

    return 0;

    }

     

    crash_dump.cpp

    int main(int argc, char** argv) {

    <!-- 将型号处理函数设置为默认

      DefuseSignalHandlers();

    <!--当向关闭的pipe 写时sigPipe信号处理

      InstallSigPipeHandler();

    <!--防止进程挂掉退出发送SIGHUP 给到进程组,

    setsid();

    <!--获取到pseudothread _fork时子进程的pipe

      unique_fd output_pipe(dup(STDOUT_FILENO));

      unique_fd input_pipe(dup(STDIN_FILENO));

     

    <!--创建与子进程通讯pipe

      unique_fd fork_exit_read, fork_exit_write;

      if (!Pipe(&fork_exit_read, &fork_exit_write)) {

        PLOG(FATAL) << "failed to create pipe";

      }

     

      pid_t forkpid = fork();

      if (forkpid == -1) {

        PLOG(FATAL) << "fork failed";

      } else if (forkpid == 0) {

       <!--子进程关闭读管道

        fork_exit_read.reset();

      } else {

        <!--父进程关闭写关闭

        fork_exit_write.reset();

    char buf;

    <!--父进程读取

    TEMP_FAILURE_RETRY(read(fork_exit_read.get(), &buf, sizeof(buf)));

    <!--父进程(crash_dump_pid)退出,pseudothread收到信号

        _exit(0);

      }

     

    <!---从父进程pseudothread中管道读取到input_pipe

    ReadCrashInfo(input_pipe, &siginfo, &info.registers, &abort_msg_address,

                          &fdsan_table_address, &gwp_asan_state, &gwp_asan_metadata);

     

     

     

     if (!ptrace_seize_thread(target_proc_fd, pseudothread_tid, &error, PTRACE_O_TRACECLONE)) {

        LOG(FATAL) << "failed to seize pseudothread: " << error;

      }

     

    <!--向父父进程pseudothread写入数据,从而父进程执行create_vm_process()

      if (TEMP_FAILURE_RETRY(write(output_pipe.get(), "\1", 1)) != 1) {

        PLOG(FATAL) << "failed to write to pseudothread";

      }

     

    <!--等待父父进程pseudothread 通过create_vm_process 进行 double clone

    pid_t vm_pid = wait_for_vm_process(pseudothread_tid);

    <!--关闭写管道,从而crash_dump读取时返回,crash_dump 执行_exit(0);父进程pseudothread收到信息进行运行

    fork_exit_write.reset();

     

    。。。。

    <!-- dump 结束,从而管道自动关闭,pseudothread退出,debuggerd_signal_handler 再次发送信号,默认信号处理函数处理

    }

     

    debuggerd

    通过socket tombstoned_intercept与tombstoned通讯,用于打印backtrace,并对其进程发送对应的信号,从而执行信号处理函数debugger_handle,输出tombstone

     

    android_os_Debug.cpp

    android_os_Debug_dumpJavaBacktraceToFileTimeout

    android_os_Debug_dumpNativeBacktraceToFileTimeout

    这里通过debuggerd 输出java/native backtrace

    Android P上Java Crash、Native Crash的异常处理流程学习

    http://ddrv.cn/a/148717

     

    Linux 信号

     

     

    名称

    信号值

    默认行为

    说明

    SIGILL

    4

    终止+coredump

    执行了非法指令. 通常是因为可执行文件本身出现错误, 或者试图执行数据段. 堆栈溢出时也有可能产生这个信号

    SIGABRT

    6

    终止+coredump

    调用abort函数生成的信号

    SIGBUS

    7

    终止+coredump

    非法地址, 包括内存地址对齐(alignment)出错。如访问一个四个字长的整数, 地址不是4的倍数。与SIGSEGV的区别在于后者是由于对合法存储地址的非法访问触发的(如访问不属于自己存储空间或只读存储空间)

    SIGFPE

    8

    终止+coredump

    在发生致命的算术运算错误时发出. 不仅包括浮点运算错误, 还包括溢出及除数为0等其它所有的算术的错误

    SIGSEGV

    11

    终止+coredump

    试图访问非自己内存,或读只读内存地址写数据。如空指针,野指针

    SIGSTKFLT

    16

    终止

    堆栈错误

    SIGPIPE

    13

    终止

    管道破裂。这个信号通常在进程间通信产生,比如采用FIFO(管道)通信的两个进程,读管道没打开或者意外终止就往管道写,写进程会收到SIGPIPE信号。此外用Socket通信的两个进程,写进程在写Socket的时候,读进程已经终止

    SIGTRAP

    5

    终止+coredump

    由断点指令或其它trap指令产生. 由debugger使用

    SIGHUP

    1

    终止

    用户终端连接(正常或非正常)结束时发出, 通常是在终端的控制进程结束时, 通知同一session内的各个作业, 这时它们与控制终端不再关联

    SIGINT

    2

    终止

    程序终止(interrupt)信号, 在用户键入INTR字符(通常是Ctrl-C)时发出,用于通知前台进程组终止进程

    SIGQUIT

    3

    终止+coredump

    和SIGINT类似, 但由QUIT字符(通常是Ctrl-\)来控制. 进程在因收到SIGQUIT退出时会产生core文件, 在这个意义上类似于一个程序错误信号

    SIGKILL

    9

    终止

    用来立即结束程序的运行. 本信号不能被阻塞、捕获和忽略。

    SIGCHLD

    17

    忽略

    子进程结束时, 父进程会收到这个信号。如果父进程没有处理这个信号,也没有等待(wait)子进程,子进程虽然终止,但是还会在内核进程表中占有表项,这时的子进程称为僵尸进程。这种情况应避免(父进程或者忽略SIGCHILD信号,或者捕捉它,或者wait它派生的子进程,或者父进程先终止,这时子进程的终止自动由init进程来接管)

    SIGCONT

    18

    继续/忽略

    让一个停止(stopped)的进程继续执行. 本信号不能被阻塞. 可以用一个handler来让程序在由stopped状态变为继续执行时完成特定的工作. 例如, 重新显示提示符..
    在进程挂起时是继续,否则是忽略

    SIGSTOP

    19

    暂停

    暂停进程的执行. 注意它和terminate以及interrupt的区别:该进程还未结束, 只是暂停执行. 本信号不能被阻塞、捕获或忽略

    SIGALRM

    14

    终止

    时钟定时信号, 计算的是实际的时间或时钟时间. alarm函数使用该信号

     

     

     

    信号

    si_code

    描述

    SIGSEGV

    SEGV_MAPERR:1

    地址没有映射到对象

    SEGV_ACCERR:2

    映射的对象的无效权限

    SIGBUS

    BUS_ADRALN: 1

    地址不对齐(自然对齐)

    BUS_ADRERR: 2

    不存在的物理地址

    BUS_OBJERR: 3

    对象指定的硬件错误

    SIGILL

    ILL_ILLOPC: 1

    违法操作码

    ILL_ILLOPN: 2

    违法操作数

    ILL_ILLADR: 3

    违法地址模式

    ILL_ILLTRP: 4

    违法陷阱

    ILL_PRVOPC: 5

    特权操作码

    ILL_PRVREG: 6

    特权寄存器

    ILL_COPROC: 7

    协进程错误

    ILL_BADSTK: 8

    内部栈错误

    SIGFPE

    FPE_INTDIV: 1

    整数被0除

    FPE_INTOVF: 2

    整数溢出

    FPE_FLTDIV: 3

    浮点数被0除

    FPE_FLTOVF: 4

    浮点数溢出

    FPE_FLTUND: 5

    浮点数下溢

    FPE_FLTRES: 6

    浮点数不精确结果

    FPE_FLTINV: 7

    无效的浮点数操作

    FPE_FLTSUB: 8

    范围外的下标

    SIGTRAP

    TRAP_BRKPT: 1

    进程中断点陷阱

    TRAP_TRACE: 2

    进程跟踪陷阱

    SIGCHLD

    CLD_EXITED: 3

    子进程已经退出

    CLD_KILLED: 4

    子进程已异常退出(无coredump)

    CLD_DUMPED: 5

    子进程已异常退出(有coredump)

    CLD_RAPPED: 6

    跟踪的子进程已经被套住

    CLD_STOPPED: 7

    子进程被停止

    CLD_CONTINUED: 8

    停止的子进程被继续

     

     

    展开全文
  • <div><p>From https://forums.couchbase.com/t/serious-delete-issue/13614 - in some cases a document being tombstoned through Sync Gateway isn't appearing on the changes feed. Need additional logging...
  • <div><p>On phone in particular, if an app is tombstoned that session can lose its information like token, app IDs, etc., and the app developer shouldn't have to write code to reset these values. ...

空空如也

空空如也

1 2 3 4 5 6
收藏数 120
精华内容 48
关键字:

tombstoned