直接查看 /proc/[pid]/status 中的 VmStk 字段可获进程栈大小（单位KB），该值为内核分配的栈段虚拟内存上限，非实时使用量；ps 和 top 不提供栈信息，其 %MEM 和 RSS 反映整体物理内存占用。
查进程栈大小直接看 /proc/[pid]/status 的 VmStk
Linux 进程的栈内存大小（不是运行时动态增长的部分，而是内核为该进程分配的栈空间上限）就记录在 /proc/[pid]/status 里，字段叫 VmStk，单位是 KB。它反映的是当前栈段（stack segment）的虚拟内存占用，不等于实际使用的栈深度，但能快速判断是否异常膨胀。
常见错误是误用 ps 或 top 查栈 —— 它们压根不提供栈信息，%MEM 和 RSS 是整个进程的物理内存占用，混在一起看会误导判断。
- 先拿到 PID：
pidof nginx或pgrep -f "python server.py" - 再读状态：
grep VmStk /proc/1234/status→ 输出类似VmStk: 136 kB - 注意：这个值通常固定（如 8MB），除非程序显式调用
setrlimit(RLIMIT_STACK, ...)修改过栈限制
用 pstack 看线程实时调用栈，但得确认它支持当前架构
pstack [pid] 本质是 gdb --batch -ex 'thread apply all bt' -p [pid] 的封装，适合快速抓取所有线程的函数调用链。但它有硬性限制：只支持与当前系统 ABI 匹配的二进制格式。
典型报错 only 32 bit objects supported 就是因为你在 64 位系统上对一个 32 位进程执行 pstack（或反过来）。Ubuntu 默认仓库的 pstack 往往只编译了单一架构版本。
- 先验证兼容性：
file /proc/[pid]/exe看是ELF 64-bit还是32-bit - 若不匹配，改用等效 gdb 命令：
gdb -p [pid] -ex 'thread apply all bt' -ex quit 2>/dev/null | grep -v "No symbol" - 注意：目标进程需未被
ptrace阻止（即没设ptrace_scope=2），否则 gdb 会失败
用 gdb 附加运行中进程看栈帧细节，但必须带调试符号
想看到变量名、源码行号、局部变量值？光有进程不行，得确保它编译时加了 -g。Release 版本的二进制即使能 attach，bt 只显示 ???，info registers 也看不出上下文。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
调试符号不是可选插件，是解析栈帧的必要条件。没有它，gdb 只能做地址级反汇编，无法映射回逻辑结构。
- 检查是否有符号：
readelf -S /path/to/binary | grep debug或file binary看是否含with debug_info - attach 命令：
gdb -p [pid]，然后bt full查完整栈帧 + 寄存器 + 局部变量 - 关键限制：若进程已
fork()出子进程，gdb 默认只跟踪原进程；要跟子进程，得提前设set follow-fork-mode child
/proc/[pid]/maps 里定位堆和栈的内存区间
栈和堆在虚拟地址空间里是真实存在的连续区域，/proc/[pid]/maps 能告诉你它们在哪、多大、有没有执行权限。这对排查栈溢出、堆碎片、mmap 冲突特别有用。
栈段通常出现在 maps 最顶部（高地址），标记为 [stack] 或 [stack:1234]；堆段则是匿名映射、从低地址向上长，开头常带 heap 字样或无名 0000000000000000 行。
- 快速过滤栈：
awk '/\[stack\]/ {print $1,$5}' /proc/[pid]/maps→ 得到地址范围和权限（如7ffea3b9e000-7ffea3bbf000 rw） - 算栈大小：
printf "0x7ffea3bbf000 - 0x7ffea3b9e000 = %d KB\n" $((0x7ffea3bbf000 - 0x7ffea3b9e000)) - 注意：
VmStk是内核视角的栈段大小，而 maps 里看到的是当前已映射的页范围 —— 两者可能不等，尤其当栈还没涨到上限时
栈的真实大小不靠猜，也不靠 top；它藏在 proc 文件系统里，也暴露在 maps 的地址段中。真正容易被跳过的，是调试符号这个前提 —— 没 -g，gdb 再熟也白搭。
