SIGSEGV简单的gloox客户端

时间:2016-01-21 09:16:07

标签: c++ gloox

我第一次尝试使用gloox 1.0.14而且我认为我使用的是最小的例子,但是我得到的是SIGSEGV。任何人都可以重现这个问题或告诉我为什么会发生这种情况以及我做错了什么?这似乎是JID对此有影响,但我希望它会抛出错误而不是segv崩溃,JID似乎对我有效,即使证书不正确或者我仍然希望它抛出代替。

auto

Sanitizer告诉我:

#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

1 个答案:

答案 0 :(得分:3)

这看起来像gloox的最新版本中的错误。在gdbvalgrind下运行代码(不使用清理程序)会显示良好的回溯。

从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的Backtrace显示:

#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帧带到那个地方,这里是这样的扇形构造:

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

cert[certListSize]明显指向现有阵列。我试图在源代码中跟踪bug,但是我对svn命令行工具并不熟悉,所以我将其留在报告上填写上游错误(好吧,我可以这样做,但请告诉我,如果有的话是我能为你做的任何事情。)