2009-09-14 22 views
6

का कारण बनता है मेरे पास std::vector<uint8_t> है जिसमें विशिष्ट ऑफ़सेट पर स्ट्रिंग शामिल हैं।std :: string :: असाइन() segfault

... 
@128 00 00 00 00 00 00 00 00 73 6F 6D 65 74 68 69 33 ........somethin 
@144 38 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ng.............. 
@160 00 00 00 00 00 00 00 00 31 2E 32 2E 33 00 00 00 ........1.2.3... 
@176 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
... 

मैं कम से डेटा निकालने ऑफसेट 136 है और यह एक std::string में डाल कोशिश कर रहा हूँ:

std::string x; 
x.assign(vec.begin()+136, vec.begin()+168); 

हालांकि, SEGFAULT करने के लिए अपने आवेदन का कारण बनता है यहाँ एक छोटा डंप है। अब मैं बहुत लिनक्स के तहत सॉफ्टवेयर विकास में नया हूँ, लेकिन मैं कैसे GDB में मेरे ऐप शुरू करने के लिए पता है और एक पश्व-अनुरेखन मिलता है, और समस्या यहाँ नीचे ट्रैक किए गए है:

(gdb) backtrace 
#0 0xb7536d78 in ??() from /lib/i686/cmov/libc.so.6 
#1 0xb7538cd5 in malloc() from /lib/i686/cmov/libc.so.6 
#2 0xb7708957 in operator new(unsigned int)() from /usr/lib/libstdc++.so.6 
#3 0xb76e4146 in std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&)() from /usr/lib/libstdc++.so.6 
#4 0xb76e63b0 in std::string::_M_mutate(unsigned int, unsigned int, unsigned int)() from /usr/lib/libstdc++.so.6 
#5 0xb76e654a in std::string::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int)() from /usr/lib/libstdc++.so.6 
#6 0x0806d651 in std::string::_M_replace_dispatch<__gnu_cxx::__normal_iterator<unsigned char const*, std::vector<unsigned char, std::allocator<unsigned char> > > > (this=0xbfffe464, __i1=..., __i2=..., __k1=..., __k2=...) at /usr/include/c++/4.3/bits/basic_string.tcc:637 
#7 0x0806d26e in std::string::replace<__gnu_cxx::__normal_iterator<unsigned char const*, std::vector<unsigned char, std::allocator<unsigned char> > > > (this=0x811c730, vec=...) at /usr/include/c++/4.3/bits/basic_string.h:1390 
#8 std::string::assign<__gnu_cxx::__normal_iterator<unsigned char const*, std::vector<unsigned char, std::allocator<unsigned char> > > > (
    this=0x811c730, vec=...) at /usr/include/c++/4.3/bits/basic_string.h:958 
#9 myclass::somemethod (this=0x811c730, vec=...) at myclass.cpp:135 

मुद्रण vec.size() 200 वापस आती है और यहां तक ​​कि अधिक पाशन वेक्टर और डेटा प्रिंट करने से मुझे कोई समस्या नहीं होती है (बिल्कुल क्रैशिंग स्निपेट से ऊपर!)।

मैं जी ++ 4.3.4 के साथ डेबियन में संकलित कर रहा हूं। इस समस्या को क्या हो सकता है इस पर कोई संकेतक?

उत्तर

13

आपके कोड में अब कहीं भी एक विसंगति रहित/हटाया जा सकता है जो अब तक लक्षण में देरी कर रहा है। जब आप मुक्त स्मृति का उपयोग करते हैं, तो ऑपरेटिंग सिस्टम तब तक जारी रखने के लिए स्वतंत्र होता है जब तक यह फिट दिखाई देता है।

प्रोग्राम को वालग्रिंड में चलाने का प्रयास करें। वालग्रिंड अपने स्वयं के मॉलोक और मुफ्त का उपयोग करता है ताकि यह आपको गलत समाचार और हटाए जाने के लिए सतर्क कर सके। compile without optimisations करने के लिए सुनिश्चित और -g साथ बनाओ:

g++ -g main.cc -o binary 
valgrind --leak-check=full ./binary 

सुनिश्चित करें कि आप एक ढेर चर दायरे से बाहर चला जाता है से एक सूचक का निर्माण नहीं करतीं करें। उदाहरण के लिए, इस नए डेवलपर्स के बीच एक आम गलती है:

int *foo() { 
    int a = 0; 
    // do something to a here 
    return &a; 
} 

एक क्षेत्र से बाहर चला गया है के रूप में, आप को मुक्त कर दिया स्मृति के लिए सूचक लौट रहे हैं।


बारे -g, मैनपेज से: ऑपरेटिंग सिस्टम के मूल स्वरूप (stabs, coff, XCOFF, या बौना 2) में डीबगिंग जानकारी का उत्पादन। जीडीबी इस डीबगिंग जानकारी के साथ काम कर सकता है।

+0

चूंकि स्मृति पहले से ही वेक्टर में है, मुझे संदेह है कि समस्या नई/मिस्चैच को हटा देती है। –

+0

मजाकिया बात यह है कि अगर मैं इसे वालग्रिंड के माध्यम से चलाता हूं, तो कोई सीगफॉल्ट नहीं होता है ... –

+0

विशिष्टताओं में बहुत गहराई से नहीं जाना, मैं एक मौजूदा एड्रिन्फो संरचना को हटाने का प्रयास कर रहा था। मैं freeaddrinfo() को कॉल कर रहा था लेकिन पॉइंटर को न्यूल पर सेट नहीं कर रहा था, इससे मुझे एक ही स्मृति को फिर से कोशिश करने और हटाने का कारण बन गया। –

संबंधित मुद्दे