gdb是工作中常用的调试工具，朋友说要介绍一下gdb的使用方法，思考了一下，遂打算整理自己的gdb经验，总结出来作为一个系列，一方面用作巩固自己的基础知识，另一方面用来分享自己的一些经验和技巧。

# 参考资料
我使用gdb的所有技巧来源于两个链接，如果想一手资料学习理解，可以进如下链接学习

## gdb文档
> https://sourceware.org/gdb

这里是gdb的官方文档位置，会每日构建文档查看，链接如下

> https://sourceware.org/gdb/current/onlinedocs/gdb.html

pdf版本
> https://sourceware.org/gdb/current/onlinedocs/gdb.pdf

## 100个gdb技巧
> https://github.com/hellogcc/100-gdb-tips

这是整理的关于gdb的中文文档

# 总结
如果需要了解gdb的使用，上述文档完全能够达成目的。接下来主要针对自己的gdb经验做一个总结，和上述内容仅技术相关。

gdb调试方法(1)-介绍

经常在不同的设备上进行调试，所以不断的attach，但是因为笔记本，台式机，linux，windows来回切换，导致tmux的窗口有时发生变化。

本来这事情很简单，没什么必要记下来，但这种事情又发生很多次了，但每次隔一段时间就忘，此时为了加强记忆，遂记录一下。

下面说明出现窗口大小问题后的处理。

# 处理办法
这个问题处理办法很简单，就是经常容易忘而已，如下
```
ctrl + b 后加上 shift + d
```
值得注意的是，这样会把原来机器的tmux挤走，所以回到原来机器上时，再attach回来即可。

tmux窗口大小问题

frp是非常热门的高性能反代应用，可以轻松的做到内网穿透，我们在开发过程中，经常需要将一些机器的调试口短暂暴露出来，这样就可以随时随地的开发了，本文基于frp介绍一下如何配置，提高开发效率
# 下载
直接上github找最近的release即可
```
https://github.com/fatedier/frp/
```
当前是0.64.0。

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

下载frp主要分主机和调试机器，主机在amd64上，所以如下下载，而其他架构则是自己的调试机器，我的机器比较多，所以下面几个机器我都配好了。
* jetson orin
* 3a6000
* rk3588
* ft2000
* hi616
* h6
* intel nuc

上述机器根据不同的架构下载不同的linux二进制即可。
```
wget https://github.com/fatedier/frp/releases/download/v0.64.0/frp_0.64.0_linux_xxx.tar.gz
```

下载之后解压，里面有服务端配置和客户端配置，下面介绍配置

# 服务端
服务端是需要公网ip的，默认简单配置如下
```
# frps.toml
bindPort = 1111                                  
auth.token = "********"            
```
运行如下
```
./frps -c frps.toml
```
然后编写一个简单的systemd service即可。
```
[Unit]
Description=FRP Server

[Service]
Type = simple
ExecStart = /pathtofrp/run.sh

[Install]
WantedBy=multi-user.target
```
然后安装激活服务即可
```
cp frps.service /usr/lib/systemd/system/
systemctl enable frps
systemctl start frps
```
# 客户端
客户端是自己的设备机器，默认22端口最多，其他情况下vnc 5900端口或者其他web端口都可以，自行配置即可，我以22为例介绍，配置如下
```
# frpc.toml
serverAddr = "***********"
serverPort = 2222                  

auth.token = "********"        

[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 3333
```
同样运行如下
```
./frpc -c frpc.toml
```
编写成服务如下
```
[Unit]
Description=FRP Client

[Service]
Type = simple
ExecStart = /pathtofrp/run.sh

[Install]
WantedBy=multi-user.target
```
激活服务如下
```
cp frpc.service /usr/lib/systemd/system/
systemctl enable frpc
systemctl start frpc
```

# 提醒
服务端暴露的端口1111是服务主机端口，而客户端链接端口2222是公网端口，这里代理设置端口3333是公网给localPort的连接的端口。

# 总结
frp作为免费开源的反代程序，其配置和使用也非常轻松易用。非常方便软件开发者进行远程开发。


使用frp远程调试开发板

tensorflow虽然现在不如torch那么流行，但是胜在稳定和早期应用的兼容落地优势，而且nvidia在安装tensorflow上几乎不会存在问题，nvidia提供了tensorflow的预编译二进制，我们可以直接拉取安装即可，本文基于nvidia的预编译二进制来说明tensorflow的安装过程
# 环境准备
首先我们可以根据nvidia的官网说明进行安装，但是需要提前知道的是，nvidia官网提供的文档通常是过时的，这种情况下我们不能全信官网。  
第一步，我们需要安装依赖，如下
```
$ sudo apt-get update
$ sudo apt-get install libhdf5-serial-dev hdf5-tools libhdf5-dev zlib1g-dev zip libjpeg8-dev liblapack-dev libblas-dev gfortran
```
然后安装python的依赖，安装之前，记得切到自己miniconda的环境，如下
```
# venv
```
值得注意的是，nvidia官网提供的安装方法，指定了当时的版本，现在的版本肯定需要升级，所以我们需要修正一下，也就是去掉版本号，如下
```
pip3 install -U future mock keras_preprocessing keras_applications  gast protobuf pybind11 cython pkgconfig packaging h5py 
```
一切就绪之后，我们登录nvidia的预发布平台查看tensorflow的二进制，如下
```
https://developer.download.nvidia.com/compute/redist/jp/v61/tensorflow/
```

![](http://139.227.85.143:9990/static/img/b7b4535ee96367138f40e50efe57b99e.image.webp)

此时直接下载即可，如下
```
wget https://developer.download.nvidia.com/compute/redist/jp/v61/tensorflow/tensorflow-2.16.1+nv24.08-cp310-cp310-linux_aarch64.whl
```
下载后安装
```
pip install tensorflow-2.16.1+nv24.08-cp310-cp310-linux_aarch64.whl
```
安装后，查看pip的list如下
```
# pip list  
Package                      Version                   Editable project location
---------------------------- ------------------------- -------------------------
absl-py                      2.3.1
astunparse                   1.6.3
certifi                      2025.8.3
charset-normalizer           3.4.3
cmake                        4.1.0
Cython                       3.1.3
filelock                     3.18.0
flatbuffers                  25.2.10
fsspec                       2025.7.0
future                       0.18.2
gast                         0.4.0
google-pasta                 0.2.0
grpcio                       1.74.0
h5py                         3.14.0
idna                         3.10
Jinja2                       3.1.6
keras                        3.11.2
Keras-Applications           1.0.8
Keras-Preprocessing          1.1.2
libclang                     18.1.1
Markdown                     3.8.2
markdown-it-py               4.0.0
MarkupSafe                   3.0.2
mdurl                        0.1.2
ml-dtypes                    0.3.2
mock                         3.0.5
mpmath                       1.3.0
namex                        0.1.0
networkx                     3.4.2
ninja                        1.13.0
numpy                        1.26.1
opt_einsum                   3.4.0
optree                       0.17.0
packaging                    25.0
pillow                       11.3.0
pip                          25.1
pkgconfig                    1.5.5
protobuf                     4.25.8
pybind11                     3.0.0
Pygments                     2.19.2
requests                     2.32.4
rich                         14.1.0
setuptools                   78.1.1
six                          1.17.0
sympy                        1.13.1
tensorboard                  2.16.2
tensorboard-data-server      0.7.2
tensorflow                   2.16.1+nv24.8
tensorflow-io-gcs-filesystem 0.37.1
termcolor                    3.1.0
torch                        2.5.0a0+872d972e41.nv24.8
torchaudio                   2.5.1a0+1661daf           /root/github/audio/src
torchvision                  0.20.1a0+3ac97aa
typing_extensions            4.14.1
urllib3                      2.5.0
Werkzeug                     3.1.3
wheel                        0.45.1
wrapt                        1.17.3
```
可以看到此环境安装了tensorflow 2.16.1版本。后续开发基于此版本

安装完成之后简单测试验证一下有效性，如下
```
import tensorflow as tf
from tensorflow.python.client import device_lib

print("Num GPUs Available: ", len(tf.config.experimental.list_physical_devices('GPU')))
print(device_lib.list_local_devices())
```
运行日志如下
```
>>> print("Num GPUs Available: ", len(tf.config.experimental.list_physical_devices('GPU')))
Num GPUs Available:  1
>>> print(device_lib.list_local_devices())
2025-08-16 12:36:53.123617: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1928] Created device /device:GPU:0 with 3786 MB memory:  -> device: 0, name: Orin, pci bus id: 0000:00:00.0, compute capability: 8.7
[name: "/device:CPU:0"
device_type: "CPU"
memory_limit: 268435456
locality {
}
incarnation: 3423392063243993720
xla_global_id: -1
, name: "/device:GPU:0"
device_type: "GPU"
memory_limit: 3970121728
locality {
  bus_id: 1
  links {
  }
}
incarnation: 6102036499595040418
physical_device_desc: "device: 0, name: Orin, pci bus id: 0000:00:00.0, compute capability: 8.7"
xla_global_id: 416903419
]
```
可以看到，正常识别到Orin平台的GPU设备了

# 总结
到这里，tensorflow的安装完成了，可以发现比安装pytorch轻松很多。

# 参考文档
> https://docs.nvidia.com/deeplearning/frameworks/install-tf-jetson-platform/index.html

Jetson-Orin-Nano-Super(5) 安装tensorflow开发环境

最近在解一个bug，其在退出的时候会出现崩溃，这种崩溃全部指向析构。经过定位，发现如果QT的对象存在父子关系，是不能够在析构中强行delete这种对象，否则就会出现循环析构，这种循环析构就会导致应用崩溃。本文基于此问题分析，强调一下QT关于对象的编程注意事项
# 为什么会出现循环析构
关于为什么会出现循环析构，其理论出现的路径应该是如下：

1. 首先，编写代码时将对象进行申请，并为其绑定了父对象
2. 然后，某一次统一的内存泄漏合规性排查，发现其new和free不成对，但是忽略了QT本身的对象内存管理机制
3. 于是乎为了满足表面语义的内存泄漏，强行在析构中进行内存删除
4. 此时，代码看似内存申请和释放对称了，也就解决了内存泄漏问题

可以看到，在常规QT的编程中，如果代码编写者对QT内存对象管理不是很清晰的话，这种情况非常常见。

那么发现循环析构的方法也很明确，本例中，gdb调试的堆栈如下
```
(gdb) bt
#0  UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#1  0x00000055717f6764 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#2  0x00000055718067ac in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:42
#3  0x00000055718067dc in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:40
#4  0x00000055717f64b4 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:230
#5  0x00000055717f6764 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#6  0x00000055718067ac in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:42
#7  0x00000055718067dc in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:40
#8  0x00000055717f64b4 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:230
#9  0x00000055717f6764 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#10 0x00000055718067ac in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:42
#11 0x00000055718067dc in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:40
......
```
此时，第一时间发现这样的堆栈肯定很疑惑，明明代码只是如下操作，而为什么对象反复在析构呢？
```
    if (m_allFrame) {
        delete m_allFrame;
        m_allFrame = nullptr;
    }
    if (m_placeHolder) {
        delete m_placeHolder;
        m_placeHolder = nullptr;
    }
```
这个其实就是QT的默认对象管理
* 当某个对象声明了父对象，则其内存声明周期由父对象管理，只有父对象删除时，其本身对象才会得到删除。

上述的含义反过来理解就是
* 如果父对象尚未销毁时，子对象被强行删除，那么当父对象销毁时，会寻找子对象进行销毁

此时子对象会销毁两次，问题也就出现了。

但是通常一个代码工程中，例子不可能这么简单，如果qt的对象绑定的父子关系比较深，那么在析构过程中，就会全部在同一个函数堆栈上析构，那么这样就看到了上图的函数堆栈。
```
#0  UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
```
# 解决问题
根据堆栈可以很明显找到代码位置为类UKUITaskBar的析构，那么定位代码非常容易，下面梳理一下对象关系

首先m_placeHolder是继承的QWidget，父对象是当前类，如下
```
m_placeHolder(new QWidget(this))
```
而m_placeHolder绑定了父对象是m_allFrame
```
m_allFrame->addWidget(m_placeHolder);
```
这里出现m_allFrame的父对象也是当前类
```
m_allFrame = new QWidget(this);
```
当前类是UKUITaskBar。

下面梳理一下父对象关系
```
UKUITaskBar--->m_placeHolder
UKUITaskBar--->m_allFrame--->m_placeHolder
```
这种父子关系，意味着m_placeHolder和m_allFrame都可以不主动delete。那么一切正常。

如果我们在`~UKUITaskBar`中主动调用如下
```
delete m_placeHolder
delete m_allFrame
```
那么可以梳理其回收的流程有几条线如下
1. 默认走QT的对象管理，由QT处理每个对象释放(情况比较复杂)
2. delete m_allFrame会主动释放m_allFrame和其子对象m_placeHolder
3. delete m_placeHolder会主动释放自身

那么从m_placeHolder的角度，这样的代码m_placeHolder释放了3次。而在实际工程中，如果对象的嵌套比较深，这种双重释放会更加严重。

最后，解决问题很简单，只要理清楚了对象的关系，直接删除不必要的释放即可。

# 总结
这个例子本身很简单，但是问题又很容易出现。本文明确出来能够很好的提醒自己这类细节问题。