जीडीबी के साथ डीबगिंग करते समय कहीं भी ब्रेकपॉइंट्स, एनटीएल

Question

के अंदर मैंने एक बहुत ही सरल प्रोग्राम बनाया जो मेरे लिए कुछ चीजें स्वचालित करता है। मैंने इसे सी ++ में लिखा और यह विंडोज पर चलता है। कोडब्लॉक्स आईडीई के अंदर से जीडीबी के साथ इसे डिबग करने के दौरान, मुझे कहीं से भी कई ब्रेकपॉइंट नहीं मिलते हैं। मुझे नहीं पता कि इस समस्या का कारण क्या हो सकता है। ब्रेकपॉइंट्स मेमोरी के मुद्दों से संबंधित प्रतीत होते हैं ... जब से मैंने एक मेमोरी रिसाव तय किया था, मैंने पाया था कि ब्रेकपॉइंट्स संख्या काफी कम हो गई है।

सटीक बात यह है कि gdb मुझसे कहता है:

Program received signal SIGTRAP, Trace/breakpoint trap. 
In ntdll!TpWaitForAlpcCompletion() (C:\Windows\system32\ntdll.dll) 

मैं अपने कार्यक्रम के अंदर इस कई कई बार मिलता है। मुझे लगता है कि मैं कुछ गलत कर रहा हूं, भले ही कार्यक्रम ठीक चल रहा है और यह पूरा करता है कि मैं इसे क्या करना चाहता हूं। क्या कोई मुझे बता सकता है कि समस्या क्या है क्योंकि मुझे नहीं पता कि कहां देखना है? अगर यह कोई समस्या नहीं है, तो क्या किसी को यह पता है कि इसे कैसे अक्षम किया जाए क्योंकि इससे मुझे खुद को सेट किए गए ब्रेकपॉइंट्स तक पहुंचने से रोकता है?

अग्रिम धन्यवाद!

संपादित करें: (जीडीबी के आदेश जहां आउटपुट का आउटपुट जोड़ना): मैं कहां देख सकता हूं कि इनमें से प्रत्येक कार्य क्या करता है, इसलिए मैं देख सकता हूं कि मैं क्या गलत कर रहा हूं?

#0 0x76fefadd in ntdll!TpWaitForAlpcCompletion() from C:\Windows\system32\ntdll.dll 
#1 0x0028e894 in ??() 
#2 0x76fb272c in ntdll!RtlCreateUserStack() from C:\Windows\system32\ntdll.dll 
#3 0x00657fb8 in ??() 
#4 0x00657fb8 in ??() 
#5 0x76f4b76a in ntdll!RtlDowncaseUnicodeChar() from C:\Windows\system32\ntdll.dll 
#6 0x02070005 in ??() 
#7 0x00000b10 in ??() 
#8 0x0028e8dc in ??() 
#9 0x76ff0b37 in ntdll!TpQueryPoolStackInformation() from C:\Windows\system32\ntdll.dll 
#10 0x038b0000 in ??() 
#11 0x00657fb8 in ??() 
#12 0x76f4b76a in ntdll!RtlDowncaseUnicodeChar() from C:\Windows\system32\ntdll.dll 
#13 0x6e6e9a5e in ??() 
#14 0x038b0000 in ??() 
#15 0x038b0000 in ??() 
#16 0x00000000 in ??() 

Answer 1

जबकि सवाल अब काफी पुराना है, यहाँ कुछ अंक किसी कि एक खोज के बाद यहां आते हैं जैसे मैंने किया था मदद कर सकता है कि कर रहे हैं WinXP। मेरे मामले में यह विंडोज 7 मेमोरी प्रबंधन निगरानी और मेरे ऐप में खराब स्मृति आवंटन दोनों से संबंधित है।

एप्लिकेशन कोड, एक स्मृति ब्लॉक कि त्रुटि से malloced गया था (बजाय GlobalAlloc() का उपयोग कर के) और के साथ मुक्त कर दिया गया था में कहानी कम करने के लिए, एक GlobalFree() (जो गलत है, के रूप में सिस्टम ढेर से एक सूचक के साथ पहुँचा था सी रनटाइम मेमोरी पूल)। हालांकि यह स्मृति (रिसाव में बहुत छोटा) मेमोरी लीक का कारण बन रहा है, यह WinXP पर परीक्षण करते समय पूरी तरह से अनजान था और पूरा कार्यक्रम स्पष्ट रूप से सही ढंग से चल रहा था।

अब जब Win7 पर निष्पादित, एक स्मृति निगरानी सुविधा कहते हैं Fault Tolerant Heap (FTH) (कि एक अपवाद उत्पन्न कर रहा है) अनुप्रयोग के इस बग का पता लगाता है: एक ही समय में यह के माध्यम से कुछ जानकारी outputting है पर

• OutputDebugString() (या शायद DbgPrint()) जिसे सरल DebugView उपकरण, या एप्लिकेशन का पता लगाने पर किसी भी डीबगर द्वारा देखा जा सकता है। इस प्रकार प्राप्त सिग्नल से पहले आप संदेशों में ऐसा कुछ देख सकते हैं:

  चेतावनी: HEAP [name_of_your।exe]:

  चेतावनी: अमान्य पता RtlFreeHeap (006B0000, 006A3698) करने के लिए निर्दिष्ट

• और (मामले एप्लिकेशन डीबग किया जा रहा है में) यह एक ब्रेकपाइंट एक डिबगर के बाहर कोई प्रभाव नहीं है कि आउटपुट, लेकिन अन्यथा समस्या को इंगित करने में मदद करनी चाहिए। उस ब्रेकपॉइंट को जीडीबी द्वारा सिगट्रैप सिग्नल के रूप में दिखाया गया है।

इस बिंदु पर आप 2 विकल्प हैं: अपने कोड में दोषपूर्ण शिक्षा को खोजने के लिए कॉल स्टैक चलने के लिए

• कोशिश (दुर्भाग्य से उस स्थिति में, bt या where gdb आदेशों दूर नहीं दिखा सकते हैं यह देखने के लिए पर्याप्त है कि मेरे कोड में ढेर को गलत तरीके से मुक्त किया गया था - अगर कोई जानता है कि एनटीएल के बजाय शुरुआती मॉड्यूल से सही कॉल स्टैक कैसे प्रदर्शित किया जाए, तो मुझे)
• जारी रखने का प्रयास करें क्योंकि एफटीएच में स्वचालित रूप से क्षमता है patc अपने बग के आसपास काम करने की कोशिश के रूप में स्मृति में ज

ढेर समस्या के समय में रोक नहीं के लिए, (कि automagic पैच भी पहले से एप्लिकेशन के अगले रन पर हो सकता है) के रूप में मोशे लेवी ने कहा, आप ऐप शुरू करने से पहले जीडीबी प्रॉम्प्ट पर handle SIGTRAP nostop सेट कर सकते हैं।

तो संक्षेप में: हाँ आपके पास स्मृति प्रबंधन के सापेक्ष आपके कोड में कुछ गड़बड़ है लेकिन कुछ मामलों में यह क्रैश होने के बिना चला सकता है। लेकिन डीबग मोड में कर्नेल आपको समस्या के रास्ते पर रखने की कोशिश करता है।

Answer 2

मैं WinDBG, देशी विंडोज डीबगर का उपयोग करने की सलाह दूंगा। यह कर्नेल मोड में संक्रमण के दौरान विशेष रूप से प्रतीकों के लिए बेहतर स्टैक निशान प्रदान करेगा।

Answer 3

वाह, आप मुझे वापस 5 साल जब मैं linux प्लेटफॉर्म :) पर gdb इस्तेमाल किया के लिए भेजा

आप जब निम्न आदेश के साथ SIGTRAP प्राप्त तोड़ने के लिए gdb रोका जा सकता है:

handle SIGTRAP nostop 

लेकिन मैं मैं यहाँ स्टीव के साथ, WinDbg इसके बजाय कोशिश करें। यह विशेष रूप से खिड़कियों के लिए बनाया गया था।

मैं सिर्फ इतना है कि कोई समस्या हुई है, जबकि मुझे द्वारा विकसित एक एप्लिकेशन Win7 पर परीक्षण:

Answer 4

मैंने क्यूटी निर्माता के साथ जीसीसी/मिंगव का उपयोग करके इस दुर्घटना का अनुभव किया।

मुझे अन्य समस्याएं भी थीं, जिनमें वे भी गलत थे (6 बाइट्स द्वारा ऑफ़सेट)। मेरे मामले में, यह एक प्रगामा पैक साबित हुआ जो कोड पर कहर बरबाद कर दिया गया।

#pragma pack(1) 
typedef struct SomeStruct 
{ 
... // structure 
} SomeStruct; 

... लेकिन मैं एक pragma पैक के साथ इसे समाप्त नहीं किया() संरचना के बाद 1 की पैकिंग समाप्त करने और डिफ़ॉल्ट बाइट संरेखण/पैकिंग पर लौटने के लिए कॉल करें:

मैं इस किया था। इसे ठीक करना:

#pragma pack(1) 
typedef struct SomeStruct 
{ 
... // structure 
} SomeStruct; 
#pragma pack() // <<-- with this line the heap corruption problem was stopped