2011-09-26 2 views
19

मैं एक वास्तव में गंदा सॉफ़्टवेयर क्रैश की जांच करने की कोशिश कर रहा हूं जो संभावित रूप से एक प्रबंधित ढेर भ्रष्टाचार से संबंधित है (क्योंकि यह कचरा संग्रह के दौरान होता है)। (एसओएस) के साथ WinDbg का उपयोग करना! Gshandles आदेश मैं"Async पिन किए गए हैंडल" क्या है?

0:000> !gchandles 
GC Handle Statistics: 
Strong Handles: 259 
Pinned Handles: 137 
Async Pinned Handles: 1 
Ref Count Handles: 79 
Weak Long Handles: 197 
Weak Short Handles: 650 
Other Handles: 0 
Statistics: 

की तरह कुछ मिलता है और मैं सिर्फ उत्सुक हूँ, एक "पिन किए गए async" एक "सामान्य" पिन किए गए संभाल और एक के बीच अंतर क्या है? और क्या मैं पा सकता हूं कि मेरे हैंडल में से कौन सा "async" है? मुझे इसके बारे में नेट पर कोई जानकारी नहीं मिली और चूंकि ऐसा लगता है कि यह काउंटर हमेशा दुर्घटनाग्रस्त हो जाता है जब यह काउंटर बिल्कुल सही होता है तो यह क्रैश के लिए प्रासंगिक हो सकता है। लेकिन फिर यह कचरा संग्रह के दौरान उपयोग की जाने वाली कुछ आंतरिक सामग्री हो सकती है ..

+0

"लेकिन आप सही हैं, मैं जांच करूंगा कि ये सभी पिन किए गए हैंडल कहां से आते हैं, संख्या काफी अधिक है .." क्या आपको कुछ दिलचस्प लगता है? – stej

उत्तर

23

Async पिन किए हैंडल विंडोज़ में ओवरलैप किए गए I/O के साथ दृढ़ता से सहसंबंधित हैं। जो OVERLAPPED तर्क का उपयोग करते हुए रीडफाइल और WriteFile के साथ एसिंक्रोनस पढ़ने और लिखने का समर्थन करता है। डिवाइस चालक पास किए गए बफर पॉइंटर को संग्रहीत करता है और सीधे प्रोग्राम के ऑपरेशन से असंक्रमित रूप से बफर से/लिखता/लिखता है। प्रबंधित रैपर विधियां BeginRead और BeginWrite हैं।

यदि बफर को जीसी ढेर में आवंटित किया जाता है तो ड्राइवर को बफर का उपयोग करने तक समाप्त होने तक इसे पिन किया जाना चाहिए। जीसी को बफर ले जाने के दौरान चालक I/O स्थानान्तरण पर काम कर रहा है विनाशकारी है, लिखने से जंक पैदा होगा और पढ़ता है जीसी ढेर को दूषित कर देगा, बफर को स्थानांतरित करने के दौरान बफर को स्थानांतरित करने से रोकने के लिए पिनिंग की आवश्यकता होती है ।

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

असिनक पिन किए गए हैंडल विशेष रूप से सीएलआर को आई/ओ पूरा होने पर बफर को स्वचालित रूप से अनपिन करने की अनुमति देने के लिए चिह्नित किए जाते हैं। जितनी जल्दी हो सके, जब I/O पूरा होने वाला पोर्ट पूरा हो जाता है और इस प्रकार क्लाइंट कोड को कॉलबैक निष्पादित करने और बफर को अनपिन करने के लिए प्रतीक्षा नहीं करना पड़ता है। जो थोड़ी देर लग सकता है जब उड़ान में बहुत सारे थ्रेडपूल धागे होते हैं। यह एक माइक्रो-ऑप्टिमाइज़ेशन है जो आपके पास एक मैक्रो में बदल जाता है, कहता है, एक वेब सर्वर जो हजारों क्लाइंट अनुरोधों को संभालता है।

यह केवल सिस्टम के प्रकारों के लिए उपयोग किया जाता है। थ्रेडिंग। ओवरलैप्डडाटा, mscorlib.dll में एक आंतरिक वर्ग है कि सीएलआर के पास विशेष ज्ञान है और मूल एवरप्लेड संरचना के लिए प्रबंधित फ़ैक्सिमाइल है जो विंडोज एपीआई फ़ंक्शन का उपयोग करता है।

लंबी कहानी छोटी, आपको वास्तव में पता है कि यदि आप क्रैश होने पर हैंडल गिनती 1 को देखते हैं तो एक ओवरलैप किया गया I/O लंबित है। जीबी आवंटित बफर के साथ ओवरलैप किए गए किसी भी देशी कोड को पिन किया गया है जो अन्यथा वास्तव में ढेर को नष्ट करने का एक अच्छा तरीका है। आपके पास बहुत सारे पिन हैंडल बीटीडब्ल्यू हैं।

+0

आपके उत्तर के लिए धन्यवाद, अब मुझे यह मिल गया - मुझे वास्तव में इस तरह की जानकारी कहीं और नहीं मिली! क्रैश प्रति देखने के लिए मुझे यह केवल एक अजीब संयोग मिलता है कि आधा दर्जन दुर्घटनाओं में डंप में मेरे पास * बिल्कुल * 1 "असिनक पिन किया गया" और 137 "पिन किया गया" हैंडल है। 137 और भी अजीब है कि एकल async एक लेकिन फिर फिर से यह केवल इसलिए हो सकता है क्योंकि मेरा प्रोग्राम हमेशा एक ही राज्य में दुर्घटनाग्रस्त हो जाता है। लेकिन आप सही हैं, मैं जांच करूंगा कि ये सभी पिन किए गए हैंडल कहां से आते हैं, संख्या काफी अधिक है .. धन्यवाद। – floyd73