https://code-agree.github.io/tags/debug/Recent content in Debug on Yu's SpaceHugo -- gohugo.ioenFri, 23 Jan 2026 17:56:12 +0800https://code-agree.github.io/blog/2026-01-23-corddump/Fri, 23 Jan 2026 17:56:12 +0800https://code-agree.github.io/blog/2026-01-23-corddump/adapter-poller 线程段错误问题定位与分析报告 #执行摘要 #问题：adapter-poller 线程在 panda-strategy 进程中多次发生段错误（SIGSEGV）。 崩溃位置：std::_Hashtable<...pandas::Adapter::ContractSpec...>::find (hashtable.h:1665) 根本原因：访问 pandas::Adapter::ContractSpec 哈希表时，this 指针无效，对象可能已被销毁。 关键发现： 崩溃发生在 adapter-poller 线程处理订单更新时 调用链：Adapter.cpp:307 → Adapter::pollCommon → std::_Hashtable::find Binance TD 代码存在类型不匹配和空指针检查缺失问题 修复建议： 修复 Binance TD 代码中的类型不匹配（std::make_unique → std::make_shared） 添加空指针检查（5 处 m_order_ws->send() 调用） 检查 Adapter 对象的生命周期管理 1. 问题现象 #1.1 系统日志显示的问题 #从系统日志 /var/log/messages 中观察到以下问题： 问题一：OOM (Out of Memory) #Jan 22 20:29:38 ... kernel: Out of memory: Killed process 2150786 (node) total-vm:45193936kB, anon-rss:28584348kB, file-rss:0kB, shmem-rss:0kB 被杀死进程：node 进程（PID: 2150786） 内存占用：约 28GB (anon-rss: 28584348kB) 结论：这是独立问题，与 adapter-poller 段错误无关 问题二：段错误 (Segmentation Fault) #Jan 23 02:46:49 .https://code-agree.github.io/blog/2026-01-19-core_ana/Mon, 19 Jan 2026 22:53:59 +0800https://code-agree.github.io/blog/2026-01-19-core_ana/摘要 #本文详细记录了一次段错误（SEGV）的完整调试过程。通过系统日志分析、地址解析、汇编代码分析和代码审查，成功定位并修复了 PerformanceMonitor 中的数组越界问题。本文展示了如何在没有完整 coredump 文件的情况下，仅凭系统日志和调试工具进行问题定位。 一、问题现象 #1.1 崩溃信息 #从 coredumpctl 获取的崩溃信息： PID: 178581 (panda_strategy-) Signal: 11 (SEGV) Timestamp: Mon 2026-01-19 21:25:12 CST Executable: /home/jason/panda/panda-strategy/Strategy/out/build/wsl-profile/panda_strategy-1.0.0 Message: Coredump entry has no core attached 关键问题：coredump 文件未保存，无法使用 GDB 直接分析。 1.2 崩溃时间点分析 #从日志文件 main.log 中可以看到： [21:25:12.816398][178634][info][strategy] Funding rates updated, total entries: 93, updated entries: 5 [21:25:12.816474][178634][info][strategy] Updated tradability parameters: 274 margin entries [21:25:12.816493][178634][info][strategy] Reference updated for 3 symbols [21:25:12.816502][178634][info][strategy] Fee rate table updated, total entries: 36, updated entries: 36 [21:25:12.https://code-agree.github.io/blog/2026-01-15-debug_procedure2/Thu, 15 Jan 2026 10:18:16 +0800https://code-agree.github.io/blog/2026-01-15-debug_procedure2/📋 问题概述 #故障现象：panda_strategy-1.0.0 程序在运行过程中发生段错误(Segmentation Fault)，进程崩溃。 崩溃时间：2026-01-15 01:04:11 CST 崩溃进程：PID 2312019 崩溃线程：adapter-poller[2312082] 信号类型：SIGSEGV (Signal 11) 🔍 排查步骤 #1. 确认崩溃信息 #1.1 使用 coredumpctl 获取崩溃基本信息 #coredumpctl info 2312019 输出结果： PID: 2312019 (panda_strategy-) UID: 1000 (jason) GID: 1000 (jason) Signal: 11 (SEGV) Timestamp: Thu 2026-01-15 01:04:11 CST (7h ago) Command Line: ./panda_strategy-1.0.0 Executable: /home/jason/panda/panda-strategy/Strategy/out/build/wsl-profile/panda_strategy-1.0.0 Storage: none Message: Process 2312019 (panda_strategy-) of user 1000 dumped core. 关键信息： ✅ 确认崩溃时间：2026-01-15 01:04:11 CST ⚠️ Storage: none - 核心转储文件未保存，但可以尝试其他方法分析 1.https://code-agree.github.io/blog/2026-01-15-debug_procedure/Thu, 15 Jan 2026 10:05:34 +0800https://code-agree.github.io/blog/2026-01-15-debug_procedure/目录 # 概述 Coredump 生成机制 环境检查与配置 Coredump 文件定位 使用 GDB 分析 Coredump 实战案例分析 最佳实践与故障排查 概述 #当 Linux 进程因段错误（SIGSEGV）、总线错误（SIGBUS）等信号异常终止时，系统可以生成 coredump 文件，记录进程崩溃时的完整内存状态。通过分析 coredump，我们可以准确定位崩溃原因，包括： 崩溃时的函数调用栈（Stack Trace） 局部变量和全局变量的值 内存布局和寄存器状态 崩溃发生的精确代码位置 本文档提供一套完整的 coredump 调试流程，从环境配置到深度分析，帮助开发者快速定位和解决程序崩溃问题。 Coredump 生成机制 #2.1 系统级配置：core_pattern #Linux 内核通过 /proc/sys/kernel/core_pattern 控制 coredump 的生成方式： # 查看当前配置 cat /proc/sys/kernel/core_pattern 常见配置模式： 传统模式：直接生成 core 文件 core 在当前工作目录生成名为 core 的文件。 Systemd-coredump 模式（现代 Linux 发行版默认）： |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e 由 systemd-coredump 服务统一管理，提供压缩、存储和查询功能。 自定义路径模式： /var/crash/core.%e.%p.%t 生成到指定目录，文件名包含可执行文件名、PID 和时间戳。https://code-agree.github.io/blog/2025-12-04-cpu_debug/Thu, 04 Dec 2025 23:27:01 +0800https://code-agree.github.io/blog/2025-12-04-cpu_debug/前言 #在高性能计算场景（如HFT交易系统、实时数据处理等）中，系统负载的精确定位至关重要。本文通过一个真实的系统负载分析案例，系统性地介绍如何使用Linux性能分析工具链，从表面现象深入到根本原因。 本文涉及的工具链 # htop/top: 实时系统资源概览 vmstat: 系统级性能统计 pidstat: 进程级性能分析 其他辅助工具: /proc文件系统、perf、strace等 第一阶段：初步观察 - htop #工具介绍 #htop是top的增强版本，提供彩色、交互式的系统监控界面。相比top，它更直观地展示： 每个CPU核心的使用率 进程/线程列表 内存和Swap使用情况 Load Average（负载平均值） 关键指标解读 #CPU使用率分布 #CPU 0-15: |||||||||||||||||| 100.0% 解读要点： 每核心独立显示：现代多核系统必须分核心观察 颜色含义（通常）： 绿色：用户态进程（user space） 红色：内核态（kernel/system） 蓝色：低优先级进程（nice） 黄色：IRQ（硬件中断） 品红：Soft IRQ（软中断） 灰色：IO Wait 青色：Steal（虚拟化环境） 异常模式识别： 全核心100%：CPU密集型负载，可能是正常业务或失控进程 某些核心100%，其他空闲：不均衡的线程分配或CPU亲和性设置 高IO Wait（灰色）：存储瓶颈 高Soft IRQ（品红）：网络包处理压力大 Load Average深度解析 #Load average: 13.08, 13.23, 12.62 常见误区：Load Average ≠ CPU使用率 Load Average的真实含义： 处于以下状态的进程/线程数量的时间加权平均值： R状态（Running/Runnable）：正在运行或等待CPU D状态（Uninterruptible Sleep）：不可中断睡眠（通常等待I/O） 三个数字的含义： 第一个：1分钟平均 第二个：5分钟平均 第三个：15分钟平均 解读规则：https://code-agree.github.io/blog/2025-07-05-dpdk_application/Sat, 05 Jul 2025 01:38:06 +0800https://code-agree.github.io/blog/2025-07-05-dpdk_application/问题背景 #在开发基于DPDK的高性能WebSocket客户端时，遇到了典型的内存管理问题。该客户端使用了QuickWS框架，集成F-Stack网络栈和OpenSSL，在连接Binance WebSocket API进行高频数据接收测试时出现段错误。 技术栈概览 # 网络栈: DPDK + F-Stack WebSocket库: QuickWS (自定义高性能框架) SSL/TLS: OpenSSL 3.x 内存分配器: Flash Allocator (自定义分配器) 缓冲区: Ring Buffer with Flash Allocator 目标: 高吞吐量实时数据接收性能测试 故障现象 #Connected to Binance WebSocket stream! fd: 1 Accepted protocols: , extensions: Thread 1 "binance_client" received signal SIGSEGV, Segmentation fault. 定位过程 #第一阶段：环境问题排查 #初始现象: 程序在DPDK初始化阶段就出现问题 EAL: Auto-detected process type: SECONDARY EAL: Fail to recv reply for request /var/run/dpdk/rte/mp_socket:bus_vdev_mp 解决方案: 清理DPDK残留资源 sudo rm -rf /var/run/dpdk/rte/mp_socket* sudo rm -rf /dev/hugepages/* 关键发现: DPDK多进程模式的资源竞争会导致初始化挂起。https://code-agree.github.io/blog/2025-07-03-strace/Thu, 03 Jul 2025 05:00:56 +0800https://code-agree.github.io/blog/2025-07-03-strace/strace 完全使用指南 #目录 # strace 简介 基础语法 核心参数详解 过滤和跟踪选项 输出格式控制 性能分析参数 实用场景示例 输出解读指南 性能调优技巧 最佳实践 1. strace 简介 #1.1 什么是 strace #strace 是 Linux 系统下的系统调用跟踪工具，它可以： 监控进程执行的所有系统调用 显示系统调用的参数和返回值 统计系统调用的执行时间和频率 跟踪信号传递过程 分析程序的系统级行为 1.2 主要用途 #性能分析 → 找出系统调用瓶颈 故障排查 → 定位程序异常原因 安全审计 → 监控程序系统访问 逆向分析 → 理解程序运行机制 系统调优 → 优化系统调用使用 2. 基础语法 #2.1 命令格式 ## 基础语法 strace [选项] [命令] strace [选项] -p <进程ID> # 示例 strace ls /tmp # 跟踪 ls 命令 strace -p 1234 # 跟踪进程ID为1234的进程 strace -e trace=network curl baidu.