2017-02-24 42 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

相關問題