这两天qwen推出了max模型,是qwen平台最强的大模型，短暂尝新了一下。

想到自己jetson也能够运行本地模型，遂基于jetson orin nano，运行了qwen3 8b在设备上。本文介绍qwen3 8b运行步骤
# qwen3 max
qwen3 max的网页版如下
> https://chat.qwen.ai/

简单问了一个问题：
![image.png](/static/img/7c38b0b7639d640bed30bc3954ec24d9.image.webp)

可以看到，这里使用了open-webui搭建的。
# qwen3 8b安装步骤
根据上面的启发，打算使用ollama搭建qwen3 8b，然后使用open-webui将其运行起来尝试，不知道能不能跑得动。

## 下载ollma
参阅官网说明`https://ollama.com/download/linux`，直接下载即可

![image.png](/static/img/a663320eb8bbfabc46c5ea2982df2165.image.webp)
```
curl -fsSL https://ollama.com/install.sh | sh
```
## 下载模型
然后进入qwen3选择对应的模型，这里我选择8b,所以如下使用
```
ollama run qwen3:8b
```
上面两步需要等很久，大概1小时。完成之后，可以ollma查看当前系统存在什么模型
```
root@kylin:~# ollama list
NAME        ID              SIZE      MODIFIED
qwen3:8b    500a1f067a9f    5.2 GB    2 hours ago
```
此时可以看到ollama默认启动端口在11434,如下
```
tcp6       0      0 localhost:11434              [::]:*                  LISTEN      12054/ollama
```
值得注意的是，这里是localhost，所以其他设备无法访问，所以需要开放一下，如下
```
# jetson_clocks
# OLLAMA_HOST=0.0.0.0 OLLAMA_MODELS=/usr/share/ollama/.ollama/models /usr/local/bin/ollama serve
```
修改后端口如下显示
```
tcp6       0      0 [::]:11434              [::]:*                  LISTEN      306996/ollama
```
curl验证一下
```
# curl 0.0.0.0:11434
Ollama is running
```
qwen3正常运行，下面稍微演示一下效果

![image.png](/static/img/157d34563328f15d3433f58b4b7385b6.image.webp)

## 安装open-webui
为了网页上使用qwen3模型，这里使用open-webui。

但是在安装之前，有个小坑。

我们jetson的环境默认python3是3.10，而open-webui是3.11的要求，所以直接venv的环境不满足要求，需要conda重新创建一个python3.11的环境，如下
```
# conda create -n openwebui python=3.11
```
创建完成之后，激活此环境,运行open-webui
```
# conda activate openwebui
# open-webui serve
```
完成之后，直接登录即可
```
http://ip:8080/
```
随便注册一个管理员账号。随便问一下如下


![image.png](/static/img/844d8bb74c163b3c0567a67c1a18865c.image.webp)

# jtop信息
可以看到，nano的GPU已经跑满了。8b对于orin来说还是很吃力的。
![image.png](/static/img/c864a29e60553dd4d9dce7934ec3373e.image.webp)

# 参考
> https://zhuanlan.zhihu.com/p/24364748492

# 总结
今天看新闻发布了qwen3 max，遂来兴趣实战了一下orin上的ollama，根据上面的办法，ollama的其他模型都可以运行，而orin的板子主要还是服务嵌入式评估，所以跑不了多大的模型，8b已经很吃力了。比8b小模型拿orin跑应该就没问题了。

Jetson-Orin-Nano-Super(6) qwen3 8b在orin上部署

在系统开发过程中，部署在设备的版本通常是release版本，所以一般是不带调试信息的，当问题出现时，我们如何排查呢？ 实际上在linux中提供了coredump的功能，当程序出现崩溃时，会给我们转储core文件，只要我们拿到core文件，就相当于拿到了问题现场，接下来就是利用gdb来分析问题了。
# core文件在哪里
对于linux系统，我们首先要查看systemd-coredump是否安装，如果systemd-coredump不安装，那么core文件是存放在默认的内核位置，内核会将其写成core，故core文件会存在启动用户的根目录，假设当前启动用户是kylin，那么core文件就在如下
```
# file /home/kylin/core
/home/kylin/core: ELF 64-bit LSB core file, ARM aarch64, version 1 (SYSV), SVR4-style, from '/usr/bin/ukui-panel', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/ukui-panel', platform: 'aarch64'
```
同样的我们可以通过内核提供的proc文件查看core的位置，如下
```
# cat /proc/sys/kernel/core_pattern
core
```
如果我们安装了systemd-coredump包，那么core文件就由systemd接管，实际位置如下
```
# cat /proc/sys/kernel/core_pattern
|/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h
```
此时core文件的位置在`/var/lib/systemd/coredump/`
# 实战
当系统内有二进制出现崩溃的时候，core文件会生成，接下来以一个实际的例子来介绍如何调试core文件。这个经验对于调试操作系统而言，非常之有用。

我手动创造了一个崩溃示例，此时可以发现coredump目录下存在如下文件
```
core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000.lz4
```
从这个信息可以知道，是kylin-vpn出现了崩溃，我们应该调试kylin-vpn，首先需要解压这个lz4文件，如下
```
# lz4 core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000.lz4
# file core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000
core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000: ELF 64-bit LSB core file, ARM aarch64, version 1 (SYSV), SVR4-style, from '/usr/bin/kylin-vpn', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/kylin-vpn', platform: 'aarch64'
```
此时假设我们直接gdb调试，看看什么效果
```
# gdb -c core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000 /usr/bin/kylin-vpn
Reading symbols from /usr/bin/kylin-vpn...
(No debugging symbols found in /usr/bin/kylin-vpn)
Core was generated by `/usr/bin/kylin-vpn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000007fa009f5a0 in QDBusMetaType::typeToSignature(int) () from /lib/aarch64-linux-gnu/libQt5DBus.so.5
```
我把关键信息贴在上面，可以看到代码出现了段错误，出现在libQt5DBus.so.5的QDBusMetaType::typeToSignature(int)函数上。

此时尝试反汇编QDBusMetaType::typeToSignature函数，发现并不能正常反汇编，如下
```
(gdb) disassemble QDBusMetaType::typeToSignature
No symbol "QDBusMetaType" in current context.
```
这是什么原因呢？其实在《gdb调试方法(4)-调试信息》里面提到过，这个动态库是发行版的动态库，自然被strip过，而strip过的动态库是找不到对应符号的。所以这种情况很正常，不要慌张。接下来逐步调试问题。

虽然我们知道了问题出现在`QDBusMetaType::typeToSignature`，但是我们还是要一步一步判断和调试问题。首先，我们留意到kylin-vpn并没有符号，所以先打上对应符号，如下
```
# dpkg -S /usr/bin/kylin-vpn
kylin-nm: /usr/bin/kylin-vpn
# dpkg -i kylin-nm-dbgsym_3.20.1.7-0k0.1tablet8.egf0.6_arm64.ddeb
```
上述安装实际上就是把kylin-vpn的符号打进系统，有gdb根据build-id加载对应的debuginfo，ddeb的内容如下
```
# dpkg -L kylin-nm-dbgsym
/.
/usr
/usr/lib
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/0f
/usr/lib/debug/.build-id/0f/470de270e27775339fd5c2cc71f2f5610d10c2.debug
/usr/lib/debug/.build-id/0f/afcd08ad5eb832b1efb97a785767c90458ef82.debug
/usr/lib/debug/.build-id/1f
/usr/lib/debug/.build-id/1f/42ddf71452964a5f507f24d4db18507046b9c7.debug
/usr/lib/debug/.build-id/41
/usr/lib/debug/.build-id/41/36dbbc90afa8a433f445f7bb964f9beea34fe2.debug
/usr/lib/debug/.build-id/63
/usr/lib/debug/.build-id/63/a064e1ef52b9ab4039a21bf4093082f844ac9f.debug
/usr/lib/debug/.build-id/83
/usr/lib/debug/.build-id/83/90208727fef2f884cf665bf868d46469056e3e.debug
/usr/lib/debug/.build-id/da
/usr/lib/debug/.build-id/da/f42bf2c9e3f18cf6716cdc49ad1811e130ee46.debug
```
此时重新gdb挂载，可以看到二进制的符号打进去了，如下
```
Reading symbols from /usr/bin/kylin-vpn...
Reading symbols from /usr/lib/debug/.build-id/0f/afcd08ad5eb832b1efb97a785767c90458ef82.debug...
```
但是，我们还是无法看到代码行数，如下
```
(gdb) l
66      main.cpp: 没有那个文件或目录.
```
所以还需要把对应的代码放进来，如下
```
scp -r source/src-vpn dest@kylin:~/
```
然后用gdb去加载自己需要的源码片段，如下
```
# gdb -c core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000 /usr/bin/kylin-vpn -d ~/src-vpn/
```
此时gdb就能正常加载所有kylin-vpn的代码了，如下
```
(gdb) l
66              break;
67          case QtCriticalMsg:
68              fprintf(log_file? log_file: stderr, "Critical: %s: %s (%s:%u, %s)\n", currentDateTime.constData(), localMsg.constData(), file, context.line, function);
69              break;
70          case QtFatalMsg:
71              fprintf(log_file? log_file: stderr, "Fatal: %s: %s (%s:%u, %s)\n", currentDateTime.constData(), localMsg.constData(), file, context.line, function);
72              break;
73          }
74
75          if (log_file)
```
我们可以基于kylin-vpn进行源码分析了。

但是，我们的问题刚刚发现实际上是在QDBusMetaType::typeToSignature函数，此时我们再反汇编一下，如下
```
(gdb) disassemble QDBusMetaType::typeToSignature
There is no field named typeToSignature
```
可以看到，因为我们加载了二进制的源码和符号，但是出问题的地方并不是我们kylin-vpn这个二进制，所以这个错误变了，从No symbol 到 no field named 。也就是说，我们需要针对typeToSignature函数来进一步调试。

根据这个信息，我们知道出问题的动态库是libQt5Dbus.so.5
```
#0  0x0000007fa009f5a0 in QDBusMetaType::typeToSignature(int) () from /lib/aarch64-linux-gnu/libQt5DBus.so.5
```
此时我们安装对应的ddeb即可，如下
```
# dpkg -S /usr/lib/aarch64-linux-gnu/libQt5DBus.so.5
libqt5dbus5:arm64: /usr/lib/aarch64-linux-gnu/libQt5DBus.so.5
# dpkg -i libqt5dbus5-dbgsym_5.12.8+dfsg_arm64.ddeb
```
这里有个小的注意点，那就是默认情况下，一些系统例如麒麟是user-merged，也就是将lib目录迁移到/usr/lib下，所以我们dpkg -S找包的时候需要追加/usr目录。

关于user merged 不是文章重点，有兴趣可以查看如下文章
> https://wiki.gentoo.org/wiki/Merge-usr

回到问题，我们再gdb调试看一下什么情况了
```
# gdb -c core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000 /usr/bin/kylin-vpn -d src-vpn/
Core was generated by `/usr/bin/kylin-vpn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  QDBusMetaType::typeToSignature (type=8) at qdbusmetatype.cpp:462
462     qdbusmetatype.cpp: 没有那个文件或目录.
[Current thread is 1 (Thread 0x7f812179b0 (LWP 17851))]
(gdb) list qdbusmetatype.cpp:1
1       in qdbusmetatype.cpp
```
可以看到，此时libQt5DBus.so.5的符号已经打上了，已经尝试在找DWARF的源码位置了，源码是qdbusmetatype.cpp，但是源码找不到。

所以反汇编是对应不到源码的，如下
```
(gdb) disassemble /m QDBusMetaType::typeToSignature
Dump of assembler code for function QDBusMetaType::typeToSignature(int):
152     in qdbusmetatype.cpp
   0x0000007fa009f4f4 <+420>:   add     x25, x22, #0x20
   0x0000007fa009f4f8 <+424>:   ldarb   w0, [x25]
   0x0000007fa009f4fc <+428>:   tbz     w0, #0, 0x7fa009f5b4 <QDBusMetaType::typeToSignature(int)+612>
   0x0000007fa009f500 <+432>:   add     x19, x19, #0x20
   0x0000007fa009f504 <+436>:   add     x23, x19, #0x28

153     in qdbusmetatype.cpp
154     in qdbusmetatype.cpp
155     in qdbusmetatype.cpp
156     in qdbusmetatype.cpp
157     in qdbusmetatype.cpp
158     in qdbusmetatype.cpp
159     in qdbusmetatype.cpp
160     in qdbusmetatype.cpp
```

所以我们需要从代码库将此文件找到，scp到机器上，如下
```
scp src/dbus/qdbusmetatype.cpp  root@91:~/core/
```
如果在gdb的运行目录，则无需手动加载，如果不在，就需要手动加载，手动加载的方式如下
```
(gdb) directory .
Source directories searched: ~/core:~/core/src-vpn:$cdir:$cwd
```
此时可以看到源码了
```
(gdb)  list qdbusmetatype.cpp:1
1       /****************************************************************************
2       **
3       ** Copyright (C) 2016 The Qt Company Ltd.
4       ** Contact: https://www.qt.io/licensing/
5       **
6       ** This file is part of the QtDBus module of the Qt Toolkit.
7       **
8       ** $QT_BEGIN_LICENSE:LGPL$
9       ** Commercial License Usage
10      ** Licensees holding valid commercial Qt licenses may use this file in
```
然后再反汇编就找得到源码了，我们找到出问题的地方，如下
```
462             if (type >= ct->size())
   0x0000007fa009f51c <+460>:   ldr     x24, [x23]
=> 0x0000007fa009f5a0 <+592>:   ldr     x24, [x23]

463                 return 0;           // type not registered with us
```
可以看到这句汇编，将x23的内容加载到x24寄存器中。其源码逻辑是 `type >= ct->size()`我们根据上下文分析一下先
```
=> 0x0000007fa009f5a0 <+592>:   ldr     x24, [x23]
   0x0000007fa009f5a4 <+596>:   ldr     w0, [x24, #4]
   0x0000007fa009f5a8 <+600>:   cmp     w20, w0
```
可以看到，这里w20是type的值，w0是ct->size()的值，为了取ct->size()，需要先取出ct的指针，也就是`ldr     x24, [x23]`，然后用ct的指针取size位置的值到w0，也就是偏移4的位置`ldr     w0, [x24, #4]`。

这里如果出现段错误，那么就是x23的值取不到了，在linux系统中，默认将0地址作为不可访问段错误地址，用来有效提醒用户。所以猜测x23的值是0。验证一下
```
(gdb) p $x23
$2 = 0
(gdb) p $w20
$1 = 8
(gdb) p type
$3 = 8
```
可以看到，因为ct已经是nullptr了，所以取size自然就段错误了，我们翻阅一下qdbusmetatype.cpp找一下ct的初始化，如下
```
    Q_GLOBAL_STATIC(QVector<QDBusCustomTypeInfo>, customTypes)
    QVector<QDBusCustomTypeInfo> *ct = customTypes();
```
可以看到，customTypes实际上是静态全局变量vector，为何会被置空为nullptr呢？

其实问题很清晰明了了，kylin-vpn会调用dbus从而调用qtbase，在系统关机过程中，qt会析构，而静态变量的析构顺序和链接顺序有关(可参考文章《使用ASAN定位全局变量构造顺序问题》)，也就是说kylin-vpn析构之前，qt的这个qdbusmetatype.o已经析构了，所以kylin-vpn在访问dbus从而访问了qdbusmetatype.o的静态变量，从而出现了空指针引用的问题。

处理这个问题就是从操作系统设计上考虑，在关机时注意多个进程之间的时序问题，从而避免不必要的coredump产生。

到这里通过gdb分析core的一次实战已经完成了。几乎所有遇到的coredump文件，通过上述这套方法都能快准狠的找出问题。

# 使用pwndbg
上面基于gdb已经能够完成调试目的了，这里再补充一下pwndbg是如何迅速找到问题的。

首先启用pwndbg，如下
```
# cat ~/.gdbinit
source ~/pwndbg/gdbinit.py
```
然后gdb加载core文件，此时pwndbg会在崩溃出打印context，如下
```
 ► 0x7fa009f5a0 <QDBusMetaType::typeToSignature(int)+592>    ldr    x24, [x23]        <Cannot dereference [0]>
   0x7fa009f5a4 <QDBusMetaType::typeToSignature(int)+596>    ldr    w0, [x24, #4]
```
```
 ► 462         if (type >= ct->size())
   463             return 0;           // type not registered with us
```
```
 X23  0
```
原因之间展示在眼前了，无需分析，pwndbg直接就告诉你问题是`Cannot dereference [0]`。迅速定位到问题。

# 总结
本文分享了非常常用的调试core的万能方法，通过此方法，后面遇到任何coredump的问题都能迎刃而解。如果使用gdb去分析和计算还是比较累，可以尝试在设备上部署pwndbg，这样存在的问题pwndbg就直接在加载时告诉你答案了，无需分析。


gdb调试方法(10)-coredump

通常调试问题的时候，经常会遇到链表，而gdb调试链表的手动计算和填入，非常麻烦。但是pwndbg提供了一个非常好的命令telescope会帮我们自动解析链表。
# telescope打印链表的条件
编程者在设计链表的时候结构各种各样，所以并不是每一种链表都是能够轻松打印的，但是一种简单的方式可以打印链表，那就是无限取值。下面介绍一下。

假设0xaaa地址的值是0xbbb，那么取到0xbbb之后，再读0xbbb的值0xccc，然后再读0xccc的值0xddd，依此类推。

这就是无限取值，它和打印链表有什么关系呢。

一个常用的双向链表如下
```
pwndbg> ptype list
type = struct list_head {
    struct list_head *prev;
    struct list_head *next;
} *
```
我们打印一下偏移值，如下
```
pwndbg> ptype /o list
type = struct list_head {
/*    0      |     8 */    struct list_head *prev;
/*    8      |     8 */    struct list_head *next;

                           /* total size (bytes):   16 */
                         } *
```
可以看到，list_head的prev永远是list_head的取值，也就意味着对list_head的无限取值就是获取list_head的prev链表的遍历。
# 实践
首先需要一个体现双向链表的示例代码，可以以之前写的lru算法为例
```
git clone https://github.com/tangfeng-648/lru.git
```
直接调试
```
gdb ./lru
```
为了方便调试，这里直接在list_add加上断点
```
pwndbg> b list_add
Breakpoint 1 at 0x400814: file list.h, line 24.
```
此时断点触发情况如下
```
   22 static inline void list_add(struct list_head *item, struct list_head *list)
   23 {
 ► 24     item->prev = list;
   25     item->next = list->next;
   26     list->next->prev = item;
   27     list->next = item;
   28 }
```
利用list可以打印这个list_head，如下
```
pwndbg> telescope list 1
00:0000│ x1 0x4132b8 —▸ 0x413e38 —▸ 0x413e68 —▸ 0x413e98 —▸ 0x413ec8 ◂— ...
pwndbg> telescope 0x413ec8 1
00:0000│  0x413ec8 —▸ 0x413ef8 —▸ 0x413f28 —▸ 0x413f58 —▸ 0x413f88 ◂— ...
```
因为list_head的偏移0是`struct list_head *prev`，所以telescope实际上是对这个list的逆序查找。

下面验证一下是否正确，如下
```
pwndbg> p list
$1 = (struct list_head *) 0x4132b8
pwndbg> p list->prev
$2 = (struct list_head *) 0x413e38
pwndbg> p list->prev->prev
$3 = (struct list_head *) 0x413e68
pwndbg> p list->prev->prev->prev
$4 = (struct list_head *) 0x413e98
pwndbg> p list->prev->prev->prev->prev
$5 = (struct list_head *) 0x413ec8
pwndbg> p list->prev->prev->prev->prev->prev
$6 = (struct list_head *) 0x413ef8
pwndbg> p list->prev->prev->prev->prev->prev->prev
$7 = (struct list_head *) 0x413f28
pwndbg> p list->prev->prev->prev->prev->prev->prev->prev
$8 = (struct list_head *) 0x413f58
pwndbg> p list->prev->prev->prev->prev->prev->prev->prev->prev
$9 = (struct list_head *) 0x413f88
```
可以看到，telescope相当于隐式的帮我们打印了这个链表。
# 如何打印next
实际上因为next相比于prev每次都要加上8的偏移，默认情况下pwndbg没有提供这样的命令，只能自行手动计算。
# 总结
本文分享了一个简单的方法来打印链表，实际上，是否能够打印链表，取决于自己对内存布局是否熟悉，如果很熟悉的情况下，可以借助这个命令简化自己的计算，如果不熟悉的情况下，建议还是手动计算吧。否则telescope给你的信息并不一定对你有用。







gdb调试方法(9)-打印链表

gdb调试方法(8)-pwndbg

在实际的gdb调试经验中，更多是多线程的调试方式，因为系统很多的设计都是基于线程的，所以某个二进制存在问题，通常存在与某个线程中，此时gdb需要正确的切换到对应线程中，然后运行。

如果只是切换到某个线程，然后调试，这个其实按照之前的文章就能够达成调试的目的，但是通常而言，需要针对某个线程做一些特殊处理，例如暂停线程，观察某个线程，观察变量。本文主要介绍这些。

# 示例代码
为了介绍这些技巧，需要准备一个多线程示例程序，如下
```
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
int a = 0;
int b = 0;
void *thread1_func(void *p_arg) 
{
    while (1) {
        a++;
        sleep(1);
    }
}

void *thread2_func(void *p_arg) 
{
    while (1) {
        b++;
        a=b;
        sleep(1);
    }
}

int main(void)
{
        pthread_t t1, t2;
        pthread_create(&t1, NULL, thread1_func, "Thread 1");
        pthread_create(&t2, NULL, thread2_func, "Thread 2");
        pthread_join(t1, NULL);
        pthread_join(t2, NULL);
}
```
编译即可
```
gcc threads.c -lpthread -g -o threads
```
# 让关心的线程运行，其他线程停止
在调试过程中，我们可以针对自己关心的线程来调试，停掉其他所有运行的线程，从而做一个排除无关因素来定位代码。主要方式如下
```
set scheduler-locking on
b 9
```
此时根据断点在第9行`a++`，此时断点触发后，b的值是恒定为1的。如下
```
(gdb) p b
$1 = 1
```
可以看到，这样的情况下，代码的两个线程并不会在continue的时候同时运行，而是停掉了thread2的运行，只运行thread1。

这种情况下，如果我们怀疑某些代码是某个线程导致的，那么可以根据此来进行排除法，从而能够很快的确定问题范围

# 让关心的线程停止，其他线程运行
和让关心的线程运行不一样的是，如果我们只是调试某个线程，但不想把所有线程停止，那么可以让其他线程运行，而自己关心的线程停止，从而调试查看变量。如下
```
(gdb) set non-stop on
(gdb) r
(gdb) set scheduler-locking off
(gdb) b threads.c:16
```
此时我们查看线程状态，可以看到thread1是运行的，而断点的thread2是停止的，如下
```
(gdb) info threads
  Id   Target Id                                     Frame
* 1    Thread 0xfffff7ff7010 (LWP 3262267) "threads" __pthread_clockjoin_ex (threadid=281474840293856, thread_return=0x0, clockid=0, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
  2    Thread 0xfffff7de71e0 (LWP 3262274) "threads" (running)
  3    Thread 0xfffff75e61e0 (LWP 3262275) "threads" thread2_func (p_arg=0xaaaaaaaaaaf0) at threads.c:17
```
所以我们查看b的值是不变的，而a的值是不断更新的。如下
```
(gdb) p b
$1 = 19
(gdb) p a
$2 = 96
(gdb) p a
$3 = 99
(gdb) p b
$4 = 19
```
# 设置观察点
在调试时，经常需要为某个变量在其作用域内设置观察点，通常而言，观察点会导致整体程序运行过慢，甚至导致代码跑飞，所以需要打上硬件观察点awatch和rwatch，而读写观察点和读观察点需要根据业务来判断，通常读观察点性能稍高一点。

但是在使用观察点的时候，还需要注意作用域，离开变量作用域的观察点就会无效。所以局部变量的观察点需要单独讨论，这里先讨论全局变量的观察点。

在多线程中，全局变量是共享数据的，这种情况下，观察点会在每个线程生效，但是如果我只想观察某个线程的全局变量，可以为这个观察点设置仅在某个线程下生效。
```
(gdb) awatch a thread 3
Hardware access (read/write) watchpoint 2: a
(gdb) c
Continuing.
[Switching to Thread 0xfffff75e61e0 (LWP 3349970)]

Thread 3 "threads" hit Hardware access (read/write) watchpoint 2: a

Value = 10
(gdb) c
Continuing.

Thread 3 "threads" hit Hardware access (read/write) watchpoint 2: a

Value = 11
```
可以看到，如果指定了thread 3，那么a的读写观察点只会在thread 3 中被触发。这样就相当于设置了仅某线程生效的观察点。从而方便自己排查问题。
# 总结
通常很多大型程序都是多线程的，当存在性能问题，或者崩溃问题时，需要使用gdb排查，但是gdb在多线程排查的时候需要一些技巧，否则每次定位程序都比较复杂，本文介绍了能够提高多线程调试效率的办法，从而能够让gdb在多线程调试时，判断问题直接了当，不浪费时间。
