Ubuntu 20重编译旧CentOS 5动态库后mremap报错错误码2

你遇到的错误码2对应EINVAL，是mremap对传入参数或映射状态不认可时返回的错误。除了版本控制导致的源码不一致，还有以下几类可能的原因：

1. 编译环境与选项差异 #

CentOS 5使用的GCC（通常是4.x版本）和Ubuntu 20的GCC（9.x版本）默认行为差异极大：

• 内存对齐规则：新GCC的默认对齐标准更严格，可能导致代码中计算的内存大小、地址偏移出现偏差，传入mremap的oldSize或address不符合映射的实际状态
• 优化级别影响：不同优化级别下，编译器可能对oldSize、newSize等变量做了常量折叠、值优化，导致实际传入内核的参数和预期不符
• 头文件宏定义差异：新旧glibc头文件中，与内存映射相关的宏（如页大小、映射标志）可能有不同定义，间接影响参数计算

2. glibc实现的细微ABI变化 #

虽然ldd显示依赖的libc.so.6路径一致，但CentOS 5的glibc版本是2.5，Ubuntu 20的是2.31，两者的mremap实现有明显差异：

• 新glibc对参数的校验更严格：旧版本可能允许oldSize略大于实际映射的内存大小，新版本直接返回EINVAL
• 内部辅助函数行为变化：内存分配相关的内部逻辑调整，导致映射的内存区域属性（如权限、对齐）与旧库不一致，无法被mremap处理

3. 内核与系统配置差异 #

Ubuntu 20的内核（5.4.x）和CentOS 5的内核（2.6.x）内存管理逻辑差异巨大：

• 内核对mremap的参数校验更严格：比如对newSize的上限、address的地址范围限制更苛刻
• ASLR（地址空间随机化）默认开启状态不同：CentOS 5默认可能关闭或限制较弱，Ubuntu 20默认全开启，导致映射的内存地址位置变化，破坏代码中隐含的地址假设
• 内存页配置差异：虽然x86_64默认页大小都是4KB，但如果代码依赖大页配置，新旧系统的大页默认设置不同会导致映射失败

4. 代码中的隐式平台依赖 #

代码可能存在针对CentOS 5的隐式假设，在Ubuntu 20中不再成立：

• 硬编码的内存页大小、地址偏移值
• 依赖CentOS 5特有的内存映射行为（比如映射区域的默认权限、相邻映射的合并规则）

排查建议 #

• 打印address、oldSize、newSize的实际值，对比旧库运行时的参数，确认是否一致
• 通过strerror(2)或perror打印具体错误描述，明确EINVAL的触发原因
• 用strace跟踪新旧库的mremap调用，查看内核返回的详细错误信息
• 对比新旧库的编译选项，重点检查优化级别、对齐参数（如-falign系列）、宏定义（如-D参数）
• 检查代码中是否有硬编码的平台相关值，替换为系统调用获取的动态值（比如用sysconf(_SC_PAGESIZE)获取页大小）

内容的提问来源于stack exchange，提问作者user439407