native 解析死锁方法

一. 概述

    我们平时在分析system_server watchdog问题时有时候会遇到一些native层的死锁问题，正常情况下我们是把所有可疑的线程调用栈全部通过symbols找到可以的死锁线程，这个方法比较耗费体力和脑力。这篇文章将会教会你一个更为简便的方法我们通过gdb调试直接打印出对应吃锁的线程。

 

二.通过GDB查看线程锁

    我们通过aosp代码找到锁的定义： http://192.99.106.107:8080/xref/android-10.0.0_r31/xref/bionic/libc/bionic/pthread_mutex.cpp#454

struct pthread_mutex_internal_t {
    _Atomic(uint16_t) state;
    uint16_t __pad;
    union {
        atomic_int owner_tid;
        PIMutex pi_mutex;
    };
    char __reserved[28];

    PIMutex& ToPIMutex() {
        return pi_mutex;
    }

    void FreePIMutex() {
    }
} __attribute__((aligned(4)));

我们发现里边有一个owner_tid，那么当有线程持锁时这个owner_tid就是已经拿着锁的线程了。

那么我们直接实践一下吧，直接制造一个在等锁的案例：

frameworks/native/services/sensorservice/SensorService.cpp
status_t SensorService::dump(int fd, const Vector<String16>& args) {
    ......
#ifdef HAS_SENSOR_CONTROL
        if (3 == args.size() && args[0] == String16("sensorsControl")) {
            if (NO_ERROR == defaultSensorControl()->executeCommand(this, args)) {
                ALOGW("pzc Sensors SensorService::dump1");
                Mutex::Autolock _l(mLock);
                ALOGW("pzc Sensors SensorService::mLock11");
                char value[PROPERTY_VALUE_MAX];
                property_get("sensor.debug", value, "0");
                if (atoi(value) == 1) {
                    ALOGW("pzc Sensors SensorService::mLock12");
                    sleep(30);
                    Mutex::Autolock _l(mLock);
                    ALOGW("pzc Sensors SensorService::mLock13");
                }
                sleep(5);
                ALOGW("pzc Sensors SensorService::dump2");
                return NO_ERROR;
            }
        }
#endif
   ......

我们这里在dumpsys sensorservice时会去拿锁30S，然后我们去注册一些sensor就可以出现等锁的情况了，中间的步骤就不一一说了，直接看gdb调试的结果吧：