सी ++ प्रोग्राम हमेशा क्रैश जबकि एक std :: स्ट्रिंग आवंटित

Question

मैं अपने अनुप्रयोग है कि दुर्घटनाओं में एक क्रैश डिबग करने के लिए कोशिश कर रहे हैं कर रही है (यानी दावा एक * glibc का पता चला * मुक्त(): अमान्य सूचक: 0x000000000070f0c0 ***) जबकि मैं एक स्ट्रिंग को एक सरल असाइन करने की कोशिश कर रहा हूं। ध्यान दें कि मैं एक लिनक्स सिस्टम पर संकलन कर रहा हूं जिसमें gcc 4.2.4 के साथ ऑप्टिमाइज़ेशन स्तर सेट -O2 सेट है। -O0 के साथ एप्लिकेशन अब दुर्घटनाग्रस्त नहीं है।

उदा।

std::string abc; 

abc = "testString"; 

लेकिन इस प्रकार यह अब तो फिर

std::string abc("testString"); 

दुर्घटनाओं अगर मैं कोड बदल मैं अपने सिर खरोंच! लेकिन दिलचस्प पैटर्न यह था कि क्रैश बाद में एप्लिकेशन में पर एक और स्ट्रिंग पर चला गया। मुझे यह अजीब लगता है कि एप्लिकेशन एक स्ट्रिंग असाइनमेंट पर लगातार क्रैश हो रहा था। एक ठेठ दुर्घटना पश्व-अनुरेखन के रूप में विचार करेंगे इस प्रकार है:

#0 0x00007f2c2663bfb5 in raise() from /lib64/libc.so.6 
(gdb) bt 
#0 0x00007f2c2663bfb5 in raise() from /lib64/libc.so.6 
#1 0x00007f2c2663dbc3 in abort() from /lib64/libc.so.6 
#2 0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487 
#3 <signal handler called> 
#4 0x00007f2c2663bfb5 in raise() from /lib64/libc.so.6 
#5 0x00007f2c2663dbc3 in abort() from /lib64/libc.so.6 
#6 0x00007f2c26680ce0 in ??() from /lib64/libc.so.6 
#7 0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>) 
    at /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:238 
#8 0x00007f2c21bd874a in PEOPLESProtocol::GetStreamName (this=<value optimized out>, 
    pRawPath=0x2342fd8 "rtmp://127.0.0.1/mp4:pop.mp4", lStreamName=@0x7f2c21bc8d20) 
    at /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491 
#9 0x00007f2c21bd9daa in PEOPLESProtocol::SignalProtocolCreated (pProtocol=0x233a4e0, customParameters=@0x7f2c21bc8de0) 
    at peoplestreamer/src/peoplesprotocol.cpp:240 

यह वास्तव में अजीब व्यवहार था और इसलिए मैं अगर वहाँ (या तो ढेर या ढेर) त्रुटि स्मृति भ्रष्टाचार के कुछ प्रकार था देखने के लिए अपने आवेदन में चारों ओर आगे प्रहार करना शुरू कर दिया है कि ऐसा हो सकता है कि यह अजीब व्यवहार हो सकता है। मैंने पीआरटी भ्रष्टाचार के लिए भी जांच की और खाली हाथ आया। कोड का दृश्य निरीक्षण के अलावा मैं भी निम्नलिखित उपकरणों की कोशिश की:

• वेलग्रिंड दोनों Memcheck और exp-ptrcheck
• बिजली की बाड़
• libsafe का उपयोग कर
• मैं साथ -fstack-रक्षक-सभी संकलित जीसीसी
• में मैं MALLOC_CHECK_ 2
• मैं फाहा चेकों के माध्यम से अपने कोड के साथ-साथ cppcheck (गलतियों के लिए जाँच करने के लिए)
• और मैं रों भाग गया करने के लिए सेट करने की कोशिश की gdb

का उपयोग कर कोड के माध्यम से tepped तो मैं सामान का एक बहुत कोशिश की है और अभी भी खाली हाथ आया। तो मैं सोच रहा था कि यह एक लिंकर मुद्दे या किसी प्रकार की लाइब्रेरी समस्या जैसी कुछ हो सकती है जो इस समस्या का कारण बन सकती है। क्या std :: स्ट्रिंग के साथ कोई ज्ञात समस्या है जो -O2 में क्रैश होने के लिए अतिसंवेदनशील है या शायद ऑप्टिमाइज़ेशन स्तर से इसका कोई लेना-देना नहीं है? लेकिन एकमात्र पैटर्न जो मैं अपनी समस्या में अब तक देख सकता हूं वह यह है कि यह हमेशा एक स्ट्रिंग पर दुर्घटनाग्रस्त प्रतीत होता है और इसलिए मैं सोच रहा था कि अगर किसी को इस तरह के व्यवहार का कारण बनने वाले किसी भी मुद्दे के बारे में पता था।

बहुत बहुत धन्यवाद!

Answer 1

क्या आप मूल दो लाइन प्रोग्राम के साथ दुर्घटना को दोहरा सकते हैं?

#include <string> 

int main() 
{ 
    std::string abc; 
    abc = "testString"; 
} 

हैं कि दुर्घटनाओं, अपने सटीक संकलन/लिंक विकल्प पोस्ट करें?

यदि नहीं, तो अपने कोड को नीचे शुरू करना शुरू करें। बग दूर होने तक चीजों को एक मुट्ठी भर में एक मुट्ठी भर दें। एक बार आपके पास अन्य परिवर्तन हो जाने के बाद आप क्रैश का कारण बन सकते हैं और इसे दूर करने के लिए हटा सकते हैं, जिससे आपको समस्या का पता लगाने में मदद मिलनी चाहिए।

Answer 2

यह आपके पिछली ट्रेस से निकाली गई सभी जानकारी का उपयोग करके प्रारंभिक अनुमान है।

आप सबसे अधिक संभावना मिश्रण और जीसीसी संस्करण, लिंकर और libstdC++ कि मेजबान मशीन पर एक असामान्य व्यवहार परिणाम मिलान कर रहे हैं:

1. libc सिस्टम के है: /lib64/libc.so.6
2. libstdC++ एक "तीसरे पक्ष" निर्देशिका में है - इस संदेह है, क्योंकि यह मुझसे कहता है यह एक अलग लक्ष्य के साथ कहीं और संकलित किया जा सकता है - /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
3. फिर भी /opt में एक और libstdC++: /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491

इसके अतिरिक्त, जीसीसी सिस्टम के एलडी को अपने आप में मिला सकता है जो आगे अजीब मेमोरी मानचित्र उपयोग कर सकता है।

Answer 3

जैसा कि आपने कहा था कि यह एक अजीब व्यवहार है।

मुझे लगता है कि आप std :: तारों के साथ संभावित बग को देखने में समय बर्बाद कर रहे हैं। जब तक आप उनका उपयोग कर रहे हैं तब तक स्ट्रिंग पूरी तरह सुरक्षित हैं।

वैसे भी, जो जानकारी आप दे रहे हैं, उसके साथ: सबसे पहले, क्या आप धागे का उपयोग कर रहे हैं? यह एक धागा समस्या हो सकती है। दूसरा, आप valgrind का उपयोग करके अपने प्रोग्राम की जांच करें। क्या आपको कोई चेतावनी नहीं है?

नोट: सबसे महत्वपूर्ण वालग्रिंड की चेतावनियां अमान्य पढ़ी गई हैं और अमान्य लेखन हैं।

पुनश्च: के रूप में टिप्पणी में कहा, तो आप शायद जी ++ का उपयोग करना चाहिए सी ++ कोड संकलित करने के लिए;

Answer 4

क्योंकि एक वर्ग जो था std :: डेटा सदस्यों के रूप में तार के लिए malloc का उपयोग कर के मुझे हुआ)। मुश्किल।