Cannot access memory at address 报错源于程序非法访问内存，非GDB问题：地址无效、权限不足、寄存器值错误；需结合 info proc mappings、bt、info registers 综合判断。
直接说结论：Cannot access memory at address 这类报错不是 GDB 的问题，而是程序当前确实无法合法访问那个地址——要么地址无效（如 0x0、已释放内存），要么权限被拒绝（如只读段写入、未映射页），要么是寄存器值本身就是垃圾数据。GDB 只是忠实地把硬件/内核的拒绝结果告诉你。
为什么 x/4xw $rsp 会报“Cannot access memory”
栈指针 $rsp 指向的位置可能根本不在当前进程的有效栈范围内。常见原因包括：
- 程序已发生栈溢出或栈被破坏，
$rsp值乱跳（比如变成0x7fff00000000这种明显越界的值） - 当前线程栈已耗尽（尤其递归过深或局部数组超大），
$rsp指向了未映射的保护页 - 你在信号处理函数中调试，而信号栈（
sigaltstack）未启用或已失效 - 使用了
-O2以上优化，编译器重排或消除栈帧，导致$rsp不再对应你预期的变量布局
验证方法：先执行 info proc mappings 查看当前进程的内存映射，确认 $rsp 所在地址是否落在 [stack] 区域内；再用 info registers rsp 看值是否合理（比如离 info proc mappings 显示的栈底不远）。
x/10xb &some_global_var 报错但变量明明存在
这通常意味着符号表缺失或地址解析失败，而非内存真不可达：
- 没加
-g编译，GDB 不知道some_global_var的地址，&some_global_var计算结果可能是0x0 - 变量被编译器优化掉了（
static且未使用、const折叠进指令等），print &some_global_var会显示Can't take address of "some_global_var" which isn't an lvalue. - 你在
core文件里调试，但core和可执行文件不匹配（路径、时间戳、strip 过），GDB 找不到符号定义 - 变量位于共享库中，而该库未加载或路径不对（
info sharedlibrary可查）
绕过方式：用 info variables some_global_var 确认符号是否存在；若存在，直接用 x/10xb 0x555555556000（换成实际地址）；若不存在，回退到带 -g -Og 重新编译。
在信号处理上下文中访问内存失败
比如在 SIGSEGV handler 里执行 x/4xw $rdi 报错，很可能是 $rdi 此时存的是出错地址（如 0x0 或非法地址），而不是有效指针：
-
siginfo_t->si_addr才是真正触发 fault 的访问地址，它比寄存器更可信 - 不要依赖通用寄存器值做内存查看——它们可能已被 handler 入口覆盖或未保存完整
- 用
handle SIGSEGV stop print让 GDB 在信号到达时立刻停住，此时寄存器和栈更接近原始状态 - 若必须分析崩溃现场，优先用
bt full+frame N+info registers，而不是盲目x某个寄存器值
真正的难点往往不在“怎么让 GDB 显示内存”，而在于判断“这个地址此刻是否本应可访问”。硬件 MMU 的拒绝是最终裁决，GDB 只是传声筒。别跟报错较劲，先查 info proc mappings、bt、info registers，三者对齐才能定位到底是代码写错、内存毁坏，还是调试时机不对。
