与第三方库的链接导致openssl出现段错误

Linking with 3rd party library causes segfault in openssl

本文关键字：段错误 错误 openssl 第三方 链接      更新时间：2023-10-16

我有一个使用OpenSSL的第三方库，我也使用Qt网络类来访问在https上运行的服务。

令人费解的是，当我用专有库链接我的应用程序时，它在调用QSslSocket期间出现分段错误，在属于OpenSSL的代码中。我所要做的就是与它链接，而不调用库中的任何函数。当我不链接到库时，一切都很好。

段故障看起来像这样

Program received signal SIGSEGV, Segmentation fault.
__strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:209
209     ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
(gdb) bt
#0  __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:209
#1  0x00007ffff72a4a5a in getrn () from /usr/lib64/libs63lib-5.16-dynr.so.10.0
#2  0x00007ffff72a4d90 in lh_insert () from /usr/lib64/libs63lib-5.16-dynr.so.10.0
#3  0x00007ffff72391fc in OBJ_NAME_add () from /usr/lib64/libs63lib-5.16-dynr.so.10.0
#4  0x00007ffff41ddba8 in SSL_library_init () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#5  0x00007ffff6b14b12 in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
#6  0x00007ffff6b16de9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
#7  0x00007ffff6b050b9 in QSslCertificate::QSslCertificate(QByteArray const&, QSsl::EncodingFormat) () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
#8  0x00007ffff6b0f429 in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
#9  0x00007ffff6b1760e in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
#10 0x00007ffff6b1230f in QSslSocket::QSslSocket(QObject*) () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
#11 0x0000000000404438 in main (argc=1, argv=0x7fffffffdb98) at s63seg.cpp:49

这是strace的最后几行。

close(4)                                = 0
mprotect(0x7fbab8e95000, 110592, PROT_READ) = 0
munmap(0x7fbabc672000, 215488)          = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=215488, ...}) = 0
mmap(NULL, 215488, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7fbabc672000
close(4)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 4
read(4, "177ELF2113>120.1"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0644, st_size=382984, ...}) = 0
mmap(NULL, 2478288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fbab8887000
mprotect(0x7fbab88db000, 2097152, PROT_NONE) = 0
mmap(0x7fbab8adb000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x54000) = 0x7fbab8adb000
mmap(0x7fbab8ae4000, 208, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbab8ae4000
close(4)                                = 0
mprotect(0x7fbab8adb000, 12288, PROT_READ) = 0
munmap(0x7fbabc672000, 215488)          = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---

你知道是什么原因引起的吗?我该如何预防呢?当其他任何方法都失败时，我可以将使用专有库的代码放在单独的可执行文件中，并使用system()或类似的方法调用它，但这不是一个很好的解决方案。

OpenSSL的两种用法是冲突的。您只能有一个CRYPTO_set_locking_callback()、CRYPTO_set_id和其他回调函数的实现。同一进程中的两个OpenSSL用户必须在这些事情上进行合作。

相关文章：