2017-02-24 7 views
0

gccでコンパイルされたcurlcppで間違ったクラッシュが発生しました。ここでは、スニペットだ -ベクトル<pair <string、string >>を返すと、gccでコンパイルされたコード(curlcpp)がクラッシュする

catch (curl_easy_exception error) { 
    // If you want to get the entire error stack we can do: 
    curlcpp_traceback errors = error.get_traceback(); 

だけ明確にする、curlcpp_tracebackはstd::vector<std::pair<std::string, std::string>>get_tracebackへのtypedefが値によって静的なベクトルを返しています。

クラッシュは割り当てポイントで発生し、ベクターが破壊されたように見えます。ここにgdbのbtがあります。

#0 0x00007f1d777c8418 in raise() from /root/ibm/shared/PIMGW1/files/lib/x86_64-linux-gnu/libc.so.6 
#1 0x00007f1d777ca01a in abort() from /root/ibm/shared/PIMGW1/files/lib/x86_64-linux-gnu/libc.so.6 
#2 0x00007f1d7780a72a in ??() from /root/ibm/shared/PIMGW1/files/lib/x86_64-linux-gnu/libc.so.6 
#3 0x00007f1d77816c18 in free() from /root/ibm/shared/PIMGW1/files/lib/x86_64-linux-gnu/libc.so.6 
#4 0x0000000000d1aa7b in deallocate (this=0x7f1d6c0c44c0, __p=<optimized out>) at /usr/include/c++/5/ext/new_allocator.h:110 
#5 deallocate (__a=..., __n=<optimized out>, __p=<optimized out>) at /usr/include/c++/5/bits/alloc_traits.h:517 
#6 _M_destroy (__size=<optimized out>, this=0x7f1d6c0c44c0) at /usr/include/c++/5/bits/basic_string.h:185 
#7 _M_dispose (this=0x7f1d6c0c44c0) at /usr/include/c++/5/bits/basic_string.h:180 
#8 ~basic_string (this=0x7f1d6c0c44c0, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/basic_string.h:543 
#9 ~pair (this=0x7f1d6c0c44c0, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_pair.h:96 
#10 _Destroy<std::pair<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> > > (__pointer=<optimized out>) at /usr/include/c++/5/bits/stl_construct.h:93 
#11 __destroy<std::pair<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >*> (__last=<optimized out>, __first=0x7f1d6c0c44c0) at /usr/include/c++/5/bits/stl_construct.h:103 
#12 _Destroy<std::pair<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >*> (__last=<optimized out>,  __first=<optimized out>) at /usr/include/c++/5/bits/stl_construct.h:126 
#13 _Destroy<std::pair<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >*, std::pair<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> > > (__last=0x7f1d6c12ffc0, __first=<optimized out>) at /usr/include/c++/5/bits/stl_construct.h:151 
#14 std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::~vector (this=0x7f1d71ad6350, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_vector.h:424 

btの#15は、上記の割り当てです。

これは、ベクターが破壊されていることを示しているようです。これはおそらく返されたベクトルなので、不自然ではありません。不明な点はクラッシュする理由です。

ご協力いただければ幸いです。

+0

デバッグビルドでクラッシュが発生しますか?もしそうなら、それをデバッグして実際に何が起きているか確認できますか? – Ap31

+0

エラーを再現するために使用できる最小限の例を示します。さもなければ、コードのいくつかの行からフードの下で何が起こっているのか把握するのは難しいです。 – skypjack

+1

私の知る限りの推測はヒープの破損であると思われます。おそらくリモートで、一見無関係なコードの部分です。ヒープの破損のバグはこのように厄介です。 –

答えて

1

私がソースコード(そのhere、右?)から見る限り、コピーは対応するミューテックスによって保護されていません。したがって、insertがメモリの再割り当てをトリガし、別のスレッドがこのベクトルをコピーしている間にメモリが破損する可能性があります。

+0

はい、これも私が思ったことです。私はコピーがアトミックな操作ではないと仮定します。これは、curlを使用するアプリケーションスレッドがより多くのチャットに遭遇したときに、なぜそれがより多く見えるかと結びついています。 – Vivek

+0

私はこれを最も可能性の高い説明と考えているので、答えとしてマークしています。 – Vivek

+0

ここの答えに基づいて、問題はcurlcppプロジェクトで解決されました - https://github.com/JosephP91/curlcpp/issues/100 – Vivek

関連する問題