尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
一个由进程内存布局异常引起的问题
前段时间业务反映某类服务器上更新了 bash 之后ssh 连上去偶发登陆失败客户端吐出错误信息如下所示图 - 0该版本 bash 为部门这边所定制但是实现上与原生版并没有不同那么这些错误从哪里来是 bash 的锅吗从上面的错误信息可以猜测异常是 bash 在启动过程中分配内存失败所导致看起来像是某些情况下该进程错误地进行了大量内存分配最后导致内存不足要确认这个事情比较简单动态内存分配到系统调用这一层上主要就两种方式 brk() 和 mmap(), 所以只要统计一下这两者的调用就可以大概估算出是否有大内存分配了。bash 是由 sshd 启动的于是 strace 跟踪了一下 sshd 进程结果发现异常发生时bash 分配的内存非常地少少到有时甚至只有几十字节也会失败几乎可以断定 bash 在内存使用上没有异常但在这期间发现一个诡异的现象Bash 一直只用 brk 在分配小内存brk() 失败后就直接退出了一般程序使用的 libc 中的 malloc (或其它类似的 malloc) 会结合 brk 和 mmap 一起使用【0】不至于 brk 一失败就分配不到内存顺手查看了下 bash 的源码发现它确实基于 brk 做了自己的内存管理并没有使用 malloc 或 mmap。但那并不是重点重点是即使是只使用 brk也不至于只能分配几十字节的内存。进程的内存布局进程的内存布局在结构上是有规律的具体来说对于 linux 系统上的进程其内存空间一般可以粗略地分为以下几大段【1】从高内存到低内存排列1、内核态内存空间其大小一般比较固定可以编译时调整但 32 位系统和 64 位系统的值不一样。2、用户态的堆栈大小不固定可以用 ulimit -s 进行调整默认一般为 8M从高地址向低地址增长。3、mmap 区域进程茫茫内存空间里的主要部分既可以从高地址到低地址延伸(所谓 flexible layout)也可以从低到高延伸(所谓 legacy layout)看进程具体情况【2】【3】。4、brk 区域紧邻数据段(甚至贴着)从低位向高位伸展但它的大小主要取决于 mmap 如何增长一般来说即使是 32 位的进程以传统方式延伸也有差不多 1 GB 的空间准确地说是 TASK_SIZE/3 - 代码段数据段参看 arch/x86/include/asm/processor.h 里宏 TASK_UNMAPPED_BASE 的定义)【4】5、数据段主要是进程里初始化和未初始化的全局数据总和当然还有编译器生成一些辅助数据结构等等)大小取决于具体进程其位置紧贴着代码段。6、代码段主要是进程的指令包括用户代码和编译器生成的辅助代码其大小取决于具体程序但起始位置根据 32 位还是 64 位一般固定(-fPIC, -fPIE等除外【5】)。以上各段(除了代码段数据段)其起始位置根据系统是否起用 randomize_va_space 一般稍有变化各段之间因此可能有随机大小的间隔千言万语不如一幅图图 - 1所以现在的问题归结为为什么目标进程的 brk 的区域突然那么小了先检查一下 bash 的内存布局图 - 2这个进程的内存布局和一般理解上有很大出入从上往下是低内存到高内存#1处为进程的代码段和数据段这两个区域一般处于进程内存空间的最低处但现在在更低处明显有动态库被映射了进来。#2处为 brk 的区域该区域还算紧临着数据段但是brk 与代码段之间也被插入了动态库而且更要命的是brk 区域向高处伸展的方向上动态库映射的区域贴的很近导致 brk 的区域事实上只有很小一个空间(0x886000 - 0x7ac000)。这并不是我们想要的内存布局我们想要的应该是长成下面这样的图 - 3看出来不同了没有两个 bash 进程都是 64 位的不同在于前者是 sshd 起的进程后者是我手动在终端上起起来的手动 cat /proc/self/maps 看了下 64 位的 cat 的进程的内存布局也是正常的图 - 4那 sshd 进程呢
RELATED

相关推荐

】[Ceiling节点]原理解析与实际应用

】[Ceiling节点]原理解析与实际应用

ing节点在Shader Graph中属于数学运算类别,它接受任意维度的矢量输入,并返回相同维度的矢量输出。这意味着它可以处理从单个浮点数到四维矢量的各种数据类型,为着色器开发提供了极大的灵活性。理解Ceiling节点的工作原理和应用场景对于创建高…

📅 2026/10/2 11:11:24
STM32与74HC32硬件键盘矩阵方案设计与优化

STM32与74HC32硬件键盘矩阵方案设计与优化

1. 项目背景与核心需求在嵌入式系统开发中,键盘矩阵是最基础也最常用的人机交互组件之一。传统方案通常直接使用MCU的GPIO引脚扫描矩阵,但当系统功能复杂、引脚资源紧张时,这种设计会面临两个关键问题:一是GPIO占用过多影响其他功…

📅 2026/10/2 19:37:54
K8s node-exporter Pod ImagePullBackOff 排查与修复(Docker Hub 国内不可达场景)

K8s node-exporter Pod ImagePullBackOff 排查与修复(Docker Hub 国内不可达场景)

生产环境 node-exporter DaemonSet 部分 Pod 持续 ImagePullBackOff,根因是节点无法访问 Docker Hub,通过迁移镜像到私有 Registry + imagePullSecret 解决。 一、问题现象 某天巡检 K8s 集群 ops 命名空间,发现 4 个 node-exporter Pod 处于 ImagePullBackOff 状态,已持续…

📅 2026/10/2 22:25:29
MORE NEWS

更多资讯

📰

企业知识库问答Agent:RAG+MCP+多模态架构实战指南

1. 项目概述:为什么企业知识库问答 Agent 不再是“锦上添花”,而是业务运转的“神经末梢”你有没有遇到过这样的场景:销售同事在客户现场被突然问到某个三年前发布的某款设备的兼容性参数,翻遍内部Wiki、邮件归档、甚至翻出2021年…

📰

基于Python深度学习的GFPGAN图片修复:从源码到实战

简介:本资源为基于Python深度学习框架的GFPGAN图片修复算法实现源码,面向具备一定Python编程与深度学习基础、关注图像修复与生成对抗网络应用的开发者与研究者,可用于老旧照片修复、面部图像增强及数字取证等场景。压缩包共62个文件&#xf…

📰

GPU推理并发上限计算器:从物理瓶颈到工程落地

1. 这不是“算力玄学”,而是一道可拆解的工程题你刷到过那种标题:“8张GPU到底能跑多少并发?”——点进去,要么是云厂商的模糊话术,要么是博主拍脑袋报个数字,再附一句“看显存、看模型、看batch size”。但…

📰

单文件AI编码代理:融合GUI操控与MCP协议的自动化利器

1. 一个念头:为什么会有这个单文件AI编码代理1.1 从“聊天机器人”到“干活机器人”我过去半年一直在折腾AI编码代理这类东西。市面上的方案不少,但大多数用起来都有一个共同的毛病:装起来太折腾。有的要配Python虚拟环境,有的要拉…

📰

AI Agent治理:防止企业数据泄露的四大缺口与落地实践

1. AI Agent 凭什么成了企业"下一个主要泄露来源"?先把它拆开看Agent 这种东西,过去一年在企业里铺开的速度比我预想得快得多。年初我还在帮几家中大型客户评估他们准备上线的 AI Agent 方案,到了年中,不少团队已经不管…

📰

FPGA定点牛顿-拉夫逊除法器:Verilog手写高吞吐除法实现

1. 这不是普通除法器:为什么牛顿-拉夫逊在FPGA里值得手搓你打开EDA工具,敲下/运算符,综合器默默给你生成一个串行移位加减的除法器——时序路径长、吞吐量低、资源占用高,仿真跑十万个周期才出一个结果。这在数字信号处理、实时控…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬