"यह" पॉइंटर स्टैक ट्रेस

Question

में दूषित हो रहा है मैंने this धागा देखा है। मेरा मामला थोड़ा अलग है और मैं यह पता लगाने के लिए संघर्ष कर रहा हूं कि "this" पॉइंटर दूषित हो रहा है।

मैं अपने QTreeView का उपयोग अपने स्वयं के मॉडल के साथ क्यूटी 4.6.2 ढांचे का उपयोग कर रहा हूं। पश्व-अनुरेखन मैं (86 फ्रेम लंबे, प्रत्यावर्तन का एक बहुत साथ, यही कारण है कि मैं में पूरी बात पेस्ट नहीं किया है है, यह इस pastebin केवल अपने कोड शामिल है।

यह अंततः QBasicAtomicInt में कुछ कोडांतरक पर segfaults :: deref, लेकिन यह स्पष्ट है कि यह और नीचे, इन तीन फ्रेम से मर गया है इसका सबूत:।

#15 0x01420fd3 in QFrame::event (this=0x942bba0, e=0xbf8eb624) at widgets/qframe.cpp:557 
#16 0x014bb382 in QAbstractScrollArea::viewportEvent (this=0x4, e=0x93f9240) at widgets/qabstractscrollarea.cpp:1036 
#17 0x0156fbd7 in QAbstractItemView::viewportEvent (this=0x942bba0, event=0xbf8eb624) at itemviews/qabstractitemview.cpp:1610 

फ्रेम 17 में, this0x942bb0 है फ्रेम 16 में, this, एक ही होना चाहिए फ्रेम 17 में यह कॉल कर रहा है के रूप में अपनी पूर्व विधि का एक ही विधि का कार्यान्वयन। हालांकि this 0x4 बन जाता है।

फ्रेम 15 में दिलचस्प रूप से पर्याप्त (फिर, फ्रेम 16 ने अपने पूर्वजों के एक ही कार्य के कार्यान्वयन को बुलाया है), 'यह' सूचक 0x942bba0 पर बहाल किया गया है।

यदि आपने पूर्ण बैकट्रैक के पेस्टबिन को देखा है, तो आप कुछ 'मान अनुकूलित आउट' देख सकते हैं। मेरे पास अनुकूलन के साथ संकलित आवेदन था; अब मेरे पास -g3 -O0 पर जीसीसी सेट है, इसलिए अगली बार जब ऐसा कुछ हो तो मेरे पास कुछ और हो सकता है। लेकिन निश्चित रूप से अब मैं इसे दुर्घटनाग्रस्त नहीं कर सकता - यह होने के लिए एक काफी मुश्किल बग है (लेकिन फिर भी ठीक करने के लिए बहुत महत्वपूर्ण है) इसलिए मुझे नहीं लगता कि यह बहुत संदिग्ध है।

अनुकूलन को देखते हुए, यह thispointer=0x4 असामान्य या निश्चित रूप से गलत है? अजीब बात यह है कि इनमें से किसी भी व्यूपोर्ट में फ्रेम में कोई वास्तविक कोड नहीं है - वे बस ईवेंट के प्रकार पर स्विच करते हैं, यह स्विच स्टेटमेंट के माध्यम से आता है, और यह अपने पूर्वजों के कार्यान्वयन को वापस करता है।

वालग्रिंड किसी भी मुद्दे को फेंकने लगते प्रतीत नहीं होता है, हालांकि मैंने अभी तक वालग्रिंड में इसे क्रैश नहीं किया है।

क्या किसी ने इस व्यवहार को पहले देखा है? इसका कारण क्या हो सकता है?

Answer 1

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

पहले स्थानीय चर के बारे में सोचना आसान है। एक गैर-अनुकूलित निर्माण में, सबकुछ स्मृति में इसकी निर्दिष्ट जगह है और कोड की प्रत्येक पंक्ति के बाद संग्रहीत किया जाना चाहिए। ऐसा इसलिए है कि डीबगर इसे पा सकता है। एक अनुकूलित निर्माण में, मान स्मृति में लिखे बिना रजिस्टरों में रह सकते हैं। यह एक अनुकूलित निर्माण के बेहतर प्रदर्शन का एक प्रमुख हिस्सा है। डीबगर इसे समझ में नहीं आता है और हमेशा स्मृति को देखेगा, इसलिए आप अक्सर गलत मान देखेंगे।

पैरामीटर के साथ भी ऐसा ही हो सकता है। यदि अनुकूलक किसी रजिस्टर में पैरामीटर पास करने का निर्णय लेता है, तो डीबगर अभी भी स्टैकफ्रेम को देखने जा रहा है। अधिक विशेष रूप से, उस स्थान पर जहां पैरामीटर कॉलिंग सम्मेलन के नियमों के अनुसार होगा।

तथ्य यह है कि स्टैक के अगले फ्रेम में मूल्य ठीक से बहाल किया गया है इंगित करता है कि जेनरेट किए गए निर्देश इस पैरामीटर से सही तरीके से काम कर रहे हैं, लेकिन डीबगर को यह नहीं पता कि यह कहां देखना है।