- 编辑 -
此问题是两个不同程序中的两个错误造成的。
链接共享对象时,fpc-3.0.0(或更高版本)将其添加到依赖项中(作为第一个依赖项):/lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 导出一个calloc
变体,它不会(总是)清除它返回的内存(详细信息如下)
OP建议的解决方法是在单独的通道中链接(使用-E
(or -Cn
)的选项fpc
),但在运行之前./ppas.sh
fixing link.res
文件。为此,我破解了这个 awk 脚本,但我确实觉得它有点笨拙:
#!/usr/bin/awk -f
$0=="INPUT(" { state=1; next; }
$0=="/lib64/ld-linux-x86-64.so.2" { state=2; next; }
$0==")" && state>0 { state=0;next; }
state==1 { print "INPUT("; state=0; }
{ print $0; }
——原答案——
听起来像是链接问题:您可能已经添加了/lib64/ld-linux-x86-64.so.2
到依赖的共享库中,这既不是必需的也没有用处。
事实上,这导致了一个calloc
返回非清零内存的版本。详细信息描述如下:https://www.linuxquestions.org/questions/programming-9/debugging-dlopen-4175668676/ https://www.linuxquestions.org/questions/programming-9/debugging-dlopen-4175668676/和这里:为什么在 gdb 中调用 calloc 似乎不会将内存清零? https://stackoverflow.com/questions/39760479/why-does-calling-calloc-in-gdb-not-appear-to-zero-out-the-memory
建议解决方案:根据示例更改链接:
- gcc -shared -o demodule.so demodule.o /lib64/ld-linux-x86-64.so.2 -lglib-2.0
+ gcc -shared -o demodule.so demodule.o -lglib-2.0
可以使用以下命令检查差异readelf -d
. Wrong:
Dynamic section at offset 0x828 contains 26 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
右输出:
Dynamic section at offset 0x7f8 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
另外,通过命令ldd demodule.so
该行包含/lib64/ld-linux-x86-64.so.2
应该是最后一个。
编辑:sourceware.org 上关于此问题的讨论:https://sourceware.org/bugzilla/show_bug.cgi?id=25486 https://sourceware.org/bugzilla/show_bug.cgi?id=25486
编辑:在 Freepascal 方面:https://bugs.freepascal.org/view.php?id=36706 https://bugs.freepascal.org/view.php?id=36706