根据jetson ai lab的了解，这里再实战一下yolo的部署，jetson ai lab提供了具体方法，本文主要是实践
# ultralytics on jetson
根据官网的指引，其安装方法也是通过容器，非常简单，如下即可
```
t=ultralytics/ultralytics:latest-jetson-jetpack6
sudo docker pull $t && sudo docker run -it --ipc=host --runtime=nvidia $t
```
待运行完成之后，默认已经在容器的bash中了，可以直接测试验证，这边以CLI作为例子实践如下。  
导出tensorrt模型
```
# yolo export model=yolov8n.pt format=engine
```
此时运行日志如下
```

Creating new Ultralytics Settings v0.0.6 file ✅
View Ultralytics Settings with 'yolo settings' or at '/root/.config/Ultralytics/settings.json'
Update Settings with 'yolo settings key=value', i.e. 'yolo settings runs_dir=path/to/dir'. For help see https://docs.ultralytics.com/quickstart/#ultralytics-settings.
Downloading https://github.com/ultralytics/assets/releases/download/v8.3.0/yolov8n.pt to 'yolov8n.pt': 100% ━━━━━━━━━━━━ 6.2MB 15.4MB/s 0.4s
WARNING ⚠️ TensorRT requires GPU export, automatically assigning device=0
Ultralytics 8.3.198 🚀 Python-3.10.12 torch-2.5.0a0+872d972e41.nv24.08 CUDA:0 (Orin, 7620MiB)
YOLOv8n summary (fused): 72 layers, 3,151,904 parameters, 0 gradients, 8.7 GFLOPs

PyTorch: starting from 'yolov8n.pt' with input shape (1, 3, 640, 640) BCHW and output shape(s) (1, 84, 8400) (6.2 MB)
requirements: Ultralytics requirement ['onnxslim>=0.1.67'] not found, attempting AutoUpdate...
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
torch 2.5.0a0+872d972e41.nv24.8 requires sympy==1.13.1; python_version >= "3.9", but you have sympy 1.14.0 which is incompatible.
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager, possibly rendering your system unusable. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv. Use the --root-user-action option if you know what you are doing and want to suppress this warning.
Collecting onnxslim>=0.1.67
  Downloading onnxslim-0.1.68-py3-none-any.whl.metadata (7.6 kB)
Requirement already satisfied: onnx in /usr/local/lib/python3.10/dist-packages (from onnxslim>=0.1.67) (1.19.0)
Collecting sympy>=1.13.3 (from onnxslim>=0.1.67)
  Downloading sympy-1.14.0-py3-none-any.whl.metadata (12 kB)
Requirement already satisfied: packaging in /usr/local/lib/python3.10/dist-packages (from onnxslim>=0.1.67) (20.9)
Collecting colorama (from onnxslim>=0.1.67)
  Downloading colorama-0.4.6-py2.py3-none-any.whl.metadata (17 kB)
Requirement already satisfied: ml_dtypes in /usr/local/lib/python3.10/dist-packages (from onnxslim>=0.1.67) (0.5.3)
Requirement already satisfied: mpmath<1.4,>=1.1.0 in /usr/local/lib/python3.10/dist-packages (from sympy>=1.13.3->onnxslim>=0.1.67) (1.3.0)
Requirement already satisfied: numpy>=1.21 in /usr/local/lib/python3.10/dist-packages (from ml_dtypes->onnxslim>=0.1.67) (1.26.4)
Requirement already satisfied: protobuf>=4.25.1 in /usr/local/lib/python3.10/dist-packages (from onnx->onnxslim>=0.1.67) (5.29.5)
Requirement already satisfied: typing_extensions>=4.7.1 in /usr/local/lib/python3.10/dist-packages (from onnx->onnxslim>=0.1.67) (4.15.0)
Requirement already satisfied: pyparsing>=2.0.2 in /usr/local/lib/python3.10/dist-packages (from packaging->onnxslim>=0.1.67) (3.2.3)
Downloading onnxslim-0.1.68-py3-none-any.whl (164 kB)
Downloading sympy-1.14.0-py3-none-any.whl (6.3 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6.3/6.3 MB 1.9 MB/s  0:00:03
Downloading colorama-0.4.6-py2.py3-none-any.whl (25 kB)
Installing collected packages: sympy, colorama, onnxslim
  Attempting uninstall: sympy
    Found existing installation: sympy 1.13.1
    Uninstalling sympy-1.13.1:
      Successfully uninstalled sympy-1.13.1

Successfully installed colorama-0.4.6 onnxslim-0.1.68 sympy-1.14.0

requirements: AutoUpdate success ✅ 16.1s
WARNING ⚠️ requirements: Restart runtime or rerun command for updates to take effect


ONNX: starting export with onnx 1.19.0 opset 19...
ONNX: slimming with onnxslim 0.1.68...
ONNX: export success ✅ 18.9s, saved as 'yolov8n.onnx' (12.2 MB)

TensorRT: starting export with TensorRT 10.3.0...
[09/11/2025-02:15:50] [TRT] [I] [MemUsageChange] Init CUDA: CPU +2, GPU +0, now: CPU 627, GPU 2981 (MiB)
[09/11/2025-02:15:52] [TRT] [I] [MemUsageChange] Init builder kernel library: CPU +927, GPU +1196, now: CPU 1597, GPU 4209 (MiB)
[09/11/2025-02:15:52] [TRT] [I] ----------------------------------------------------------------
[09/11/2025-02:15:52] [TRT] [I] Input filename:   yolov8n.onnx
[09/11/2025-02:15:52] [TRT] [I] ONNX IR version:  0.0.9
[09/11/2025-02:15:52] [TRT] [I] Opset version:    19
[09/11/2025-02:15:52] [TRT] [I] Producer name:    pytorch
[09/11/2025-02:15:52] [TRT] [I] Producer version: 2.5.0
[09/11/2025-02:15:52] [TRT] [I] Domain:
[09/11/2025-02:15:52] [TRT] [I] Model version:    0
[09/11/2025-02:15:52] [TRT] [I] Doc string:
[09/11/2025-02:15:52] [TRT] [I] ----------------------------------------------------------------
TensorRT: input "images" with shape(1, 3, 640, 640) DataType.FLOAT
TensorRT: output "output0" with shape(1, 84, 8400) DataType.FLOAT
TensorRT: building FP32 engine as yolov8n.engine
[09/11/2025-02:15:52] [TRT] [I] Local timing cache in use. Profiling results in this builder pass will not be stored.

[09/11/2025-02:18:36] [TRT] [I] Detected 1 inputs and 3 output network tensors.
[09/11/2025-02:18:37] [TRT] [I] Total Host Persistent Memory: 389248
[09/11/2025-02:18:37] [TRT] [I] Total Device Persistent Memory: 0
[09/11/2025-02:18:37] [TRT] [I] Total Scratch Memory: 0
[09/11/2025-02:18:37] [TRT] [I] [BlockAssignment] Started assigning block shifts. This will take 164 steps to complete.
[09/11/2025-02:18:37] [TRT] [I] [BlockAssignment] Algorithm ShiftNTopDown took 12.5611ms to assign 7 blocks to 164 nodes requiring 18841600 bytes.
[09/11/2025-02:18:37] [TRT] [I] Total Activation Memory: 18841600
[09/11/2025-02:18:37] [TRT] [I] Total Weights Memory: 12727300
[09/11/2025-02:18:37] [TRT] [I] Engine generation completed in 164.86 seconds.
[09/11/2025-02:18:37] [TRT] [I] [MemUsageStats] Peak memory usage of TRT CPU/GPU memory allocators: CPU 1 MiB, GPU 260 MiB
[09/11/2025-02:18:37] [TRT] [I] [MemUsageStats] Peak memory usage during Engine building and serialization: CPU: 2400 MiB
TensorRT: export success ✅ 187.0s, saved as 'yolov8n.engine' (13.8 MB)

Export complete (188.4s)
Results saved to /ultralytics
Predict:         yolo predict task=detect model=yolov8n.engine imgsz=640
Validate:        yolo val task=detect model=yolov8n.engine imgsz=640 data=coco.yaml
Visualize:       https://netron.app
💡 Learn more at https://docs.ultralytics.com/modes/export
```
这里在做预测时，先看一下待预测的图片内容，如下

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

接下来使用这个tensorrt的模型预测，如下
```
# yolo predict model=yolov8n.engine source='https://ultralytics.com/images/bus.jpg'
```
运行的日志信息如下
```
WARNING ⚠️ Unable to automatically guess model task, assuming 'task=detect'. Explicitly define task for your model, i.e. 'task=detect', 'segment', 'classify','pose' or 'obb'.
Ultralytics 8.3.198 🚀 Python-3.10.12 torch-2.5.0a0+872d972e41.nv24.08 CUDA:0 (Orin, 7620MiB)
Loading yolov8n.engine for TensorRT inference...
[09/11/2025-02:21:01] [TRT] [I] Loaded engine size: 13 MiB
[09/11/2025-02:21:01] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in IExecutionContext creation: CPU +0, GPU +18, now: CPU 0, GPU 30 (MiB)

Downloading https://ultralytics.com/images/bus.jpg to 'bus.jpg': 100% ━━━━━━━━━━━━ 134.2KB 1.2MB/s 0.1s
image 1/1 /ultralytics/bus.jpg: 640x640 4 persons, 1 bus, 7.7ms
Speed: 26.9ms preprocess, 7.7ms inference, 130.4ms postprocess per image at shape (1, 3, 640, 640)
Results saved to /ultralytics/runs/detect/predict
💡 Learn more at https://docs.ultralytics.com/modes/predict

```

可以看到其目标识别的预测值还是非常准确的

![bus.jpg](/static/img/37291e18e65142606ef18dce08e9d78c.bus.webp)

# ultralytics-yolo webtest
jetson ai lab还提供了webtest，命令也非常简单，首先安装examples包，如下
```
# venv
# pip install jetson-examples
```
然后直接运行即可
```
# reComputer run ultralytics-yolo
INFO: machine[nvidia jetson orin nano engineering reference developer kit super] confirmed...
run example：ultralytics-yolo
----example init----
CONFIG_FILE_PATH=/root/miniconda3/envs/virtual/lib/python3.10/site-packages/reComputer/scripts/ultralytics-yolo/config.yaml
yq is already installed.
jq is already installed.
jq-1.6
32.6.1 35.3.1 35.4.1 35.5.0 36.3.0 36.4.0
L4T VERSION 36.4.4 is not in the allowed versions list.
The JetPack versions currently supported by this container are: 32.6.1 35.3.1 35.4.1 35.5.0 36.3.0 36.4.0.
For more information : https://github.com/Seeed-Projects/jetson-examples
An error occurred. Exiting...
```
可以看到，examples的仓库没有及时更新，所以不支持36.4.4.这里需要对比一下版本差异。

对于r36.4.0的版本内容，可以如下查阅
> https://developer.nvidia.cn/embedded/jetson-linux-r3640

文档是
> https://docs.nvidia.com/jetson/archives/r36.4/ReleaseNotes/Jetson_Linux_Release_Notes_r36.4.pdf

而对于r36.6.4的版本本容，可以如下查阅
> https://developer.nvidia.cn/embedded/jetson-linux-r3644

文档是
> https://docs.nvidia.com/jetson/archives/r36.4.4/ReleaseNotes/Jetson_Linux_Release_Notes_r36.4.4.pdf

经过确认，相关tensorrt和yolo变化不大，应该可以复用。下面尝试修改jetson_examples的仓库

进入python安装路径，尝试定位到这个判断
```
/root/miniconda3/envs/virtual/lib/python3.10/site-packages/reComputer/scripts/ultralytics-yolo/run.sh
```
可以发现其基于config.yaml配置，查看config.yaml，如下
```
# The tested JetPack versions.
ALLOWED_L4T_VERSIONS:
  - 32.6.1
  - 35.3.1
  - 35.4.1
  - 35.5.0
  - 36.3.0
  - 36.4.0
```
这里新增一条，如下
```
# The tested JetPack versions.
ALLOWED_L4T_VERSIONS:
  - 32.6.1
  - 35.3.1
  - 35.4.1
  - 35.5.0
  - 36.3.0
  - 36.4.0
  - 36.4.4
```
同时，run.sh也做了二次校验判断，如下
```
# Determine the Docker image based on L4T version
if [[ "$L4T_VERSION" == "32.6.1" ]]; then
    IMAGE_NAME="yaohui1998/ultralytics-jetpack4:1.0"
elif [[ "$L4T_VERSION" == "35.3.1" || "$L4T_VERSION" == "35.4.1" || "$L4T_VERSION" == "35.5.0" ]]; then
    IMAGE_NAME="yaohui1998/ultralytics-jetpack5:1.0"
elif [[ "$L4T_VERSION" == "36.3.0" ]]; then
    IMAGE_NAME="yaohui1998/ultralytics-jetpack6:1.0"
elif [[ "$L4T_VERSION" == "36.4.0" ]]; then
    IMAGE_NAME="yaohui1998/ultralytics-jetpack61:v1.0"
else
    echo "Error: L4T version $L4T_VERSION is not supported."
    exit 1
fi
```
新增36.4.4即可，如下
```
elif [[ "$L4T_VERSION" == "36.4.4" ]]; then
    IMAGE_NAME="yaohui1998/ultralytics-jetpack61:v1.0"
else
```
这里相当于尝试使用jetpack6.1来在我当前的硬件和内核环境跑yolo

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

因为yolo主要还是现成的模型来转换，tensorrt版本不变化太大其实没关系。但是是否能跑，现在还打个问号？接下来继续实践

再根据run.sh的docker运行指令，可以知道其启动方式，如下
```
if [ $(docker ps -a -q -f name=^/${CONTAINER_NAME}$) ]; then
    echo "Container $CONTAINER_NAME already exists. Starting and attaching..."
    echo "Please open http://127.0.0.1:5000 to access the WebUI."
    docker start $CONTAINER_NAME
    docker exec -it $CONTAINER_NAME /bin/bash
else
    echo "Container $CONTAINER_NAME does not exist. Creating and starting..."
    docker run -it \
        --name $CONTAINER_NAME \
        --privileged \
        --network host \
        -v ~/yolo_models/:/usr/src/ultralytics/models/ \
        -v /tmp/.X11-unix:/tmp/.X11-unix \
        -v /dev/*:/dev/* \
        -v /etc/localtime:/etc/localtime:ro \
        --runtime nvidia \
        $IMAGE_NAME
fi
```
可以看到，第一遍会启动一个名字为ultralytics-yolo的容器，后面每次都是重新打开此容器。默认情况下启动了5000端口作为webui。
```
docker exec -it ultralytics-yolo /bin/bash
```
然后进入5000端口，样式如下

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

# yolo on webcam
以webcam做个实验，测试yolov8和yolov10的效果

首先插入双目摄像头，让容器重新加载/dev目录，如下
```
# docker restart ultralytics-yolo
# docker exec -it ultralytics-yolo /bin/bash
# ls /dev/video*
/dev/video0  /dev/video1  /dev/video2  /dev/video3
```

然后识别键盘如下

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

推理日志如下
```
# docker logs ultralytics-yolo -f
0: 640x640 (no detections), 7.1ms
Speed: 1.9ms preprocess, 7.1ms inference, 1.4ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.1ms
Speed: 1.9ms preprocess, 7.1ms inference, 1.4ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.1ms
Speed: 1.9ms preprocess, 7.1ms inference, 1.3ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.2ms
Speed: 1.9ms preprocess, 7.2ms inference, 1.5ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.3ms
Speed: 2.1ms preprocess, 7.3ms inference, 1.7ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.2ms
Speed: 2.0ms preprocess, 7.2ms inference, 1.5ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.2ms
Speed: 1.9ms preprocess, 7.2ms inference, 1.4ms postprocess per image at shape (1, 3, 640, 640)

0: 640x640 (no detections), 7.2ms
Speed: 2.0ms preprocess, 7.2ms inference, 1.4ms postprocess per image at shape (1, 3, 640, 640)
```

可以看到orin运行yolo n/s 都比较流畅，不是很吃力

![image.png](/static/img/ca744a8936f26b5370b7d3a2ee6d981a.image.webp)
# 总结
本文基于ai lab的容器内容做了一个实践，简单的在orin上运行了yolo8和yolo11的多个模型。

Jetson-Orin-Nano-Super(8) yolo ultralytics 部署

上一个文章参考了网络的文章实战部署了qwen3 8b的llm模型，进一步的本文继续参考网络资源，上手在orin上部署stable diffusion
# jetson ai lab
nvidia有一个ai lab，可以游玩很多的ai相关内容
> https://www.jetson-ai-lab.com/

本文主要实战部署stable-diffusion，所以参考文档如下
> https://www.jetson-ai-lab.com/tutorial_stable-diffusion.html

可以看到，这里面会使用jetson containers的git仓库，先进去浏览一番

> https://github.com/dusty-nv/jetson-containers.git

可以看到这个仓库有很多的ai示例可以尝试

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

这里找到stable diffusion的示例，其实际上是拉取了docker hub的容器镜像，如下
> https://hub.docker.com/r/dustynv/stable-diffusion-webui

可以看到当前最新的版本是r36.4.0

下面开始根据文档的步骤演示运行stable-diffusion-webui
# 实战
首先国内的docker需要设置一下proxy。
```
# mkdir -p /etc/systemd/system/docker.service.d
# cat /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:9981"
Environment="HTTPS_PROXY=http://127.0.0.1:9981"
# systemctl daemon-reload
# systemctl restart docker
```
这里不同的proxy换成不同端口即可。

然后按照文档，这里尝试安装最新的版本r36.4.0，如下
```
# jetson-containers run dustynv/stable-diffusion-webui:r36.4.0
```
但是发现此版本的python的numpy要求，venv无法提供，所以降级版本到r36.2.0，如下
```
# jetson-containers run dustynv/stable-diffusion-webui:r36.2.0
```
因为在国内，所以默认模型下载不了，这是安装上述配置挂上代理后下载的。  

下载完成之后，运行后发现docker的运行参数是如下
```
docker run --runtime nvidia --env NVIDIA_DRIVER_CAPABILITIES=compute,utility,graphics -it --rm --network host --shm-size=8g --volume /root/jetson-containers/jetson-containers/packages/diffusion/stable-diffusion-webui/openai/:/opt/stable-diffusion-webui/openai/ --volume /tmp/argus_socket:/tmp/argus_socket --volume /etc/enctune.conf:/etc/enctune.conf --volume /etc/nv_tegra_release:/etc/nv_tegra_release --volume /tmp/nv_jetson_model:/tmp/nv_jetson_model --volume /var/run/dbus:/var/run/dbus --volume /var/run/avahi-daemon/socket:/var/run/avahi-daemon/socket --volume /var/run/docker.sock:/var/run/docker.sock --volume /root/jetson-containers/jetson-containers/data:/data -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro --device /dev/snd --device /dev/bus/usb --device /dev/i2c-0 --device /dev/i2c-1 --device /dev/i2c-2 --device /dev/i2c-4 --device /dev/i2c-5 --device /dev/i2c-7 --device /dev/i2c-9 -v /run/jtop.sock:/run/jtop.sock --name jetson_container_20250910_222642 dustynv/stable-diffusion-webui:r36.2.0
```
第一个问题出现了，容器内的模型无法下载，这里观察到默认的data在/root/jetson-containers/jetson-containers/data上，如下
```
--volume /root/jetson-containers/jetson-containers/data:/data 
```
所以进入目录手动下载模型到指定目录，如下
```
# cd /root/jetson-containers/jetson-containers/data/models/stable-diffusion/models/Stable-diffusion
# wget https://huggingface.co/runwayml/stable-diffusion-v1-5/resolve/main/v1-5-pruned-emaonly.safetensors
```
下载后继续尝试运行，发现CLIPTokenizer无法加载，日志如下
```
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]
Version: v1.7.0
Commit hash: cf2772fab0af5573da775e7437e6acdca424f26e
Launching Web UI with arguments: --data=/data/models/stable-diffusion --enable-insecure-extension-access --xformers --listen --port=7860
Style database not found: /data/models/stable-diffusion/styles.csv
Loading weights [6ce0161689] from /data/models/stable-diffusion/models/Stable-diffusion/v1-5-pruned-emaonly.safetensors
/opt/stable-diffusion-webui/extensions-builtin/stable-diffusion-webui-tensorrt/ui_trt.py:64: GradioDeprecationWarning: The `style` method is deprecated. Please set these arguments in the constructor instead.
  with gr.Row().style(equal_height=False):
Running on local URL:  http://0.0.0.0:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 15.5s (prepare environment: 3.1s, import torch: 4.8s, import gradio: 1.9s, setup paths: 1.5s, initialize shared: 0.2s, other imports: 1.3s, setup codeformer: 0.1s, load scripts: 0.9s, create ui: 0.9s, gradio launch: 0.8s).
Creating model from config: /opt/stable-diffusion-webui/configs/v1-inference.yaml
/opt/stable-diffusion-webui/openai/clip-vit-large-patch14
creating model quickly: OSError
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 973, in _bootstrap
    self._bootstrap_inner()
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/stable-diffusion-webui/modules/initialize.py", line 147, in load_model
    shared.sd_model  # noqa: B018
  File "/opt/stable-diffusion-webui/modules/shared_items.py", line 128, in sd_model
    return modules.sd_models.model_data.get_sd_model()
  File "/opt/stable-diffusion-webui/modules/sd_models.py", line 531, in get_sd_model
    load_model()
  File "/opt/stable-diffusion-webui/modules/sd_models.py", line 634, in load_model
    sd_model = instantiate_from_config(sd_config.model)
  File "/opt/stable-diffusion-webui/repositories/stable-diffusion-stability-ai/ldm/util.py", line 89, in instantiate_from_config
    return get_obj_from_str(config["target"])(**config.get("params", dict()))
  File "/opt/stable-diffusion-webui/repositories/stable-diffusion-stability-ai/ldm/models/diffusion/ddpm.py", line 563, in __init__
    self.instantiate_cond_stage(cond_stage_config)
  File "/opt/stable-diffusion-webui/repositories/stable-diffusion-stability-ai/ldm/models/diffusion/ddpm.py", line 630, in instantiate_cond_stage
    model = instantiate_from_config(config)
  File "/opt/stable-diffusion-webui/repositories/stable-diffusion-stability-ai/ldm/util.py", line 89, in instantiate_from_config
    return get_obj_from_str(config["target"])(**config.get("params", dict()))
  File "/opt/stable-diffusion-webui/repositories/stable-diffusion-stability-ai/ldm/modules/encoders/modules.py", line 103, in __init__
    self.tokenizer = CLIPTokenizer.from_pretrained(version)
  File "/usr/local/lib/python3.10/dist-packages/transformers/tokenization_utils_base.py", line 1809, in from_pretrained
    raise EnvironmentError(
OSError: Can't load tokenizer for 'openai/clip-vit-large-patch14'. If you were trying to load it from 'https://huggingface.co/models', make sure you don't have a local directory with the same name. Otherwise, make sure 'openai/clip-vit-large-patch14' is the correct path to a directory containing all relevant files for a CLIPTokenizer tokenizer.
```
根据日志初步怀疑也是docker内的环境拿到openai/clip-vit-large-patch14，所以也是手动下载
```
# cd /root/jetson-containers/jetson-containers/packages/diffusion/stable-diffusion-webui
# mkdir openai && cd openai
# apt install git-lfs
# git clone https://huggingface.co/openai/clip-vit-large-patch14
```
经过漫长的等待，终于拉取了其13G的模型内容，如下
```
# cd /root/jetson-containers/jetson-containers/packages/diffusion/stable-diffusion-webui/openai/clip-vit-large-patch14    .
```
到这里还需要判断和分享一下日志报错的情况

这里根据报错的日志，看到launch.py的运行参数是如下
```
Launching Web UI with arguments: --data=/data/models/stable-diffusion --enable-insecure-extension-access --xformers --listen --port=7860
```
所以其实际运行的命令可能是如下
```
# python3 launch.py --data=/data/models/stable-diffusion --enable-insecure-extension-access --xformers --listen --port=7860
```
根据python的堆栈可以知道代码出错在`/usr/local/lib/python3.10/dist-packages/transformers/tokenization_utils_base.py`的1809行，进入确认一下，找到from_pretrained函数的声明，如下
```
def from_pretrained(cls, pretrained_model_name_or_path: Union[str, os.PathLike], *init_inputs, **kwargs):
```
可以看到，这是`pretrained_model_name_or_path: Union[str, os.PathLike]`计算的路径，而pretrained_model_name_or_path可以从如下确认
```
  File "/opt/stable-diffusion-webui/repositories/stable-diffusion-stability-ai/ldm/modules/encoders/modules.py", line 103, in __init__
    self.tokenizer = CLIPTokenizer.from_pretrained(version)
```
继续查看modules.py，确认version的值
```
def __init__(self, version="openai/clip-vit-large-patch14", device="cuda", max_length=77,
                 freeze=True, layer="last", layer_idx=None):  # clip-vit-base-patch32
```
合理猜测需要的路径实际上应该是容器里这个位置
```
/opt/stable-diffusion-webui/openai/clip-vit-large-patch14
```
为了保险，这里打上python的print再确认一遍，这里在from_pretrained打印pretrained_model_name_or_path的值，如下
```
print(os.path.abspath(pretrained_model_name_or_path))
```
手动运行，得到print打印，如下
```
# python3 launch.py --data=/data/models/stable-diffusion --enable-insecure-extension-access --xformers --listen --port=7860
/opt/stable-diffusion-webui/openai/clip-vit-large-patch14
```
猜测完全正确，需要在/opt/stable-diffusion-webui有对应的目录，现在返回去看docker run的参数，可以发现，/opt/stable-diffusion-webui并不是对外挂载的，所以需要新增一条volume参数，将之前下载的模型位置挂载到docker的这个目录上，如下
```
--volume /root/jetson-containers/jetson-containers/packages/diffusion/stable-diffusion-webui/openai/:/opt/stable-diffusion-webui/openai/
```
所以总的运行命令如下
```
docker run --runtime nvidia --env NVIDIA_DRIVER_CAPABILITIES=compute,utility,graphics -it --rm --network host --shm-size=8g --volume /root/jetson-containers/jetson-containers/packages/diffusion/stable-diffusion-webui/openai/:/opt/stable-diffusion-webui/openai/ --volume /tmp/argus_socket:/tmp/argus_socket --volume /etc/enctune.conf:/etc/enctune.conf --volume /etc/nv_tegra_release:/etc/nv_tegra_release --volume /tmp/nv_jetson_model:/tmp/nv_jetson_model --volume /var/run/dbus:/var/run/dbus --volume /var/run/avahi-daemon/socket:/var/run/avahi-daemon/socket --volume /var/run/docker.sock:/var/run/docker.sock --volume /root/jetson-containers/jetson-containers/data:/data -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro --device /dev/snd --device /dev/bus/usb --device /dev/i2c-0 --device /dev/i2c-1 --device /dev/i2c-2 --device /dev/i2c-4 --device /dev/i2c-5 --device /dev/i2c-7 --device /dev/i2c-9 -v /run/jtop.sock:/run/jtop.sock --name jetson_container_20250910_222642 dustynv/stable-diffusion-webui:r36.2.0 
```
此时运行日志如下
```
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]
Version: v1.7.0
Commit hash: cf2772fab0af5573da775e7437e6acdca424f26e
Launching Web UI with arguments: --data=/data/models/stable-diffusion --enable-insecure-extension-access --xformers --listen --port=7860
Style database not found: /data/models/stable-diffusion/styles.csv
Loading weights [6ce0161689] from /data/models/stable-diffusion/models/Stable-diffusion/v1-5-pruned-emaonly.safetensors
/opt/stable-diffusion-webui/extensions-builtin/stable-diffusion-webui-tensorrt/ui_trt.py:64: GradioDeprecationWarning: The `style` method is deprecated. Please set these arguments in the constructor instead.
  with gr.Row().style(equal_height=False):
Running on local URL:  http://0.0.0.0:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 18.2s (prepare environment: 3.4s, import torch: 5.6s, import gradio: 2.2s, setup paths: 1.7s, initialize shared: 0.3s, other imports: 1.8s, setup codeformer: 0.2s, load scripts: 1.1s, create ui: 0.9s, gradio launch: 0.8s).
Creating model from config: /opt/stable-diffusion-webui/configs/v1-inference.yaml
Applying attention optimization: xformers... done.
Model loaded in 10.8s (load weights from disk: 2.2s, create model: 0.8s, apply weights to model: 6.5s, apply half(): 0.2s, load textual inversion embeddings: 0.6s, calculate empty prompt: 0.3s).
```
没有看到报错了，同时可以看到默认开放端口在0.0.0.0:7860，所以可以同一网络环境下打开这个页面，做一下尝试.

这里简单生成了一下麒麟嵌入式系统的图片，还是比较准确的，如下。

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

再生成一张，查看一下gpu占用情况

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

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

可以看到，内存5个多G，GPU全跑，整体比qwen3 8b要顺利很多，orin nano运行stable diffusion 并不是很吃力。

最后，其实jetson-ai-lab的文档也告诉你了，容器是这样如下运行的，
```
cd /opt/stable-diffusion-webui && python3 launch.py \
  --data=/data/models/stable-diffusion \
  --enable-insecure-extension-access \
  --xformers \
  --listen \
  --port=7860
```

# 参考
> https://www.jetson-ai-lab.com/tutorial_stable-diffusion.html  
> https://zhuanlan.zhihu.com/p/1889443308834624504  

# 总结
本次参考网络资源实战了stable diffusion，相比于ollma，因为是容器运行，所以代理的问题比较难搞，但是总归来说有办法的，整体还是非常轻松能够跑起来的。使用两个小时下来，orin 发热不严重，完全满足可以长期运行。

Jetson-Orin-Nano-Super(7) stable-diffusion-webui 部署

这两天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给你的信息并不一定对你有用。





