SIGSEGV简单gloox客户端

Question

我第一次尝试使用gloox1.0.14，我想我使用的是最简单的例子，但是很糟糕，我得到了一个SIGSEGV。有人能重复这个问题吗?或者告诉我为什么会发生这种情况，我做错了什么？JID似乎对此有影响，但我希望它会抛出一个错误，而不是分段崩溃，而且JID对我来说是有效的，即使证书不正确，或者我仍然希望它抛出的任何东西。

#include <cstdlib>

#include "gloox/client.h"

int main() {
  gloox::JID jid("segv@jabber.de");
  gloox::Client client(jid, "password");
  client.connect();
  return EXIT_SUCCESS;
}

消毒剂告诉我：

ASAN:SIGSEGV
=================================================================
==27028==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f6357f79acd bp 0x7ffcca7c1a50 sp 0x7ffcca7c17d0 T0)
    #0 0x7f6357f79acc  (/lib64/libgnutls.so.30+0x99acc)
    #1 0x7f6357f7b49a  (/lib64/libgnutls.so.30+0x9b49a)
    #2 0x7f6357f7bb18 in gnutls_x509_crt_verify (/lib64/libgnutls.so.30+0x9bb18)
    #3 0x7f635a4ad54b in gloox::GnuTLSClient::verifyAgainstCAs(gnutls_x509_crt_int*, gnutls_x509_crt_int**, int) (/lib64/libgloox.so.13+0xbd54b)
    #4 0x7f635a4ad6bf in gloox::GnuTLSClient::getCertInfo() (/lib64/libgloox.so.13+0xbd6bf)
    #5 0x7f635a4afd6c in gloox::GnuTLSBase::handshake() (/lib64/libgloox.so.13+0xbfd6c)
    #6 0x7f635a4afbc0 in gloox::GnuTLSBase::decrypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/lib64/libgloox.so.13+0xbfbc0)
    #7 0x7f635a4490bb in gloox::ConnectionTCPClient::recv(int) (/lib64/libgloox.so.13+0x590bb)
    #8 0x7f635a4c297d in gloox::ConnectionTCPBase::receive() (/lib64/libgloox.so.13+0xd297d)
    #9 0x7f635a4541d7 in gloox::ClientBase::connect(bool) (/lib64/libgloox.so.13+0x641d7)
    #10 0x4014d7 in main test.cc:8
    #11 0x7f6358aa357f in __libc_start_main (/lib64/libc.so.6+0x2057f)
    #12 0x401198 in _start (test+0x401198)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==27028==ABORTING

我是通过以下方式编制的：

c++ -fsanitize=address -fsanitize=undefined -ggdb -std=c++14 -Wall -Wextra -Wpedantic -Wconversion -Wsign-conversion -lgloox main.cc

Answer 1

这看起来像gloox的最新版本中的一个bug。在gdb或valgrind下运行代码(没有杀菌剂)显示了很好的回溯效果。

从英勇点到问题所在的全部回溯：

==29533==    at 0x62B558D: verify_crt (verify.c:602)
==29533==    by 0x62B6F57: _gnutls_verify_crt_status (verify.c:936)
==29533==    by 0x62B75CC: gnutls_x509_crt_verify (verify.c:1329)
==29533==    by 0x4EF254B: gloox::GnuTLSClient::verifyAgainstCAs(gnutls_x509_crt_int*, gnutls_x509_crt_int**, int) (tlsgnutlsclient.cpp:227)
==29533==    by 0x4EF26BF: gloox::GnuTLSClient::getCertInfo() (tlsgnutlsclient.cpp:157)
==29533==    by 0x4EF4D6C: gloox::GnuTLSBase::handshake() (tlsgnutlsbase.cpp:138)
==29533==    by 0x4EF4BC0: gloox::GnuTLSBase::decrypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (tlsgnutlsbase.cpp:70)
==29533==    by 0x4E8E0BB: gloox::ConnectionTCPClient::recv(int) (connectiontcpclient.cpp:169)
==29533==    by 0x4F0797D: gloox::ConnectionTCPBase::receive() (connectiontcpbase.cpp:115)
==29533==    by 0x4E991D7: gloox::ClientBase::connect(bool) (clientbase.cpp:212)
==29533==    by 0x400DAC: main (main.cc:9)

来自gdb的回溯显示：

#0  verify_crt (cert=0xbebebebebebebebe, trusted_cas=trusted_cas@entry=0x0, tcas_size=tcas_size@entry=0, flags=flags@entry=0, output=output@entry=0x7fffffffce90, _issuer=_issuer@entry=0x7fffffffce98, 
    now=1455405710, max_path=0x7fffffffce94, end_cert=true, nc=0x602000007a50, func=0x0) at verify.c:602
#1  0x00007ffff46bcf58 in _gnutls_verify_crt_status (certificate_list=certificate_list@entry=0x7fffffffcf08, clist_size=clist_size@entry=1, trusted_cas=trusted_cas@entry=0x0, tcas_size=tcas_size@entry=0, 
    flags=flags@entry=0, purpose=purpose@entry=0x0, func=0x0) at verify.c:936
#2  0x00007ffff46bd5cd in gnutls_x509_crt_verify (cert=cert@entry=0xbebebebebebebebe, CA_list=CA_list@entry=0x0, CA_list_length=CA_list_length@entry=0, flags=flags@entry=0, verify=verify@entry=0x7fffffffcf24)
    at verify.c:1329
#3  0x00007ffff6bee54c in gloox::GnuTLSClient::verifyAgainstCAs (this=this@entry=0x61400000fc40, cert=0xbebebebebebebebe, CAList=CAList@entry=0x0, CAListSize=CAListSize@entry=0) at tlsgnutlsclient.cpp:227
#4  0x00007ffff6bee6c0 in gloox::GnuTLSClient::getCertInfo (this=0x61400000fc40) at tlsgnutlsclient.cpp:157
#5  0x00007ffff6bf0d6d in gloox::GnuTLSBase::handshake (this=0x61400000fc40) at tlsgnutlsbase.cpp:138
#6  0x00007ffff6bf0bc1 in gloox::GnuTLSBase::decrypt (this=0x61400000fc40, 
    data="\024\003\003\000\001\001\026\003\003\000(\373\336\267\221q\256\266\344\363\022\367 C\022\233\351\251\065\036\355\070\362\217\264\370\003\206+\"\201r^\355\067I\203Y\213\350\301")
    at tlsgnutlsbase.cpp:70
#7  0x00007ffff6b8a0bc in gloox::ConnectionTCPClient::recv (this=<optimized out>, timeout=<optimized out>) at connectiontcpclient.cpp:169
#8  0x00007ffff6c0397e in gloox::ConnectionTCPBase::receive (this=0x60c00000bec0) at connectiontcpbase.cpp:115
#9  0x00007ffff6b951d8 in gloox::ClientBase::connect (this=0x7fffffffd410, block=<optimized out>) at clientbase.cpp:212
#10 0x00000000004013a8 in main () at main.cc:9

cert=0xbebebebebebebebe指针是故障点。它是从tlsgnutlsclient.cpp:157的第4帧带到那个地方的，这里有这样的fanny结构：

157     m_certInfo.chain = verifyAgainstCAs( cert[certListSize], 0 /*CAList*/, 0 /*CAListSize*/ );

cert[certListSize]明显地指向了现有数组。我试图在源代码中跟踪这个bug，但是我对svn命令行工具不太熟悉，所以我把这个放在报告中以填充上游bug (好的，我可以这样做，但是如果有什么我可以为您做的话，请告诉我)。