एक बार फिर परमाणु रिसाव और वीसीएल बग के बारे में

परिचय

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

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

अतिप्रवाह तंत्र का विवरण

एक अन्य शिकायत प्राप्त करने के बाद एक ला "मेमोरी से बाहर", हमने पाया कि परमाणुओं की तालिका कंट्रोलऑफ़्स <हेक्साडेसिमल आईडी> के तत्वों से भरी हुई है। ये तत्व प्रत्येक एप्लिकेशन की शुरुआत में दिखाई देते हैं (और हमारा एप्लिकेशन सर्वर इंस्टेंस लॉन्च करता है, प्रत्येक कनेक्शन के लिए एक), और हमेशा के लिए तालिका में बने रहें।

कंट्रोलपेटास में InitControls से कोड के अनुभाग पर फिर से विचार करें - जैसा कि ऊपर वर्णित लेख में किया गया है:

WindowAtomString := Format('Delphi%.8X',[GetCurrentProcessID]); WindowAtom := GlobalAddAtom(PChar(WindowAtomStrinjg)); ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]); ControlAtom := GlobalAddAtom(PChar(ControlAtomString)); RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString)); 

बहुत अंतिम पंक्ति, जैसा कि यह लग रहा था, एक परमाणु भी बनाता है। एक नया संदेश प्रकार दर्ज करते समय, तालिका में एक नया परमाणु जोड़ा जाता है, जिसमें हर बार एक नया नाम होता है। समस्या यह है कि RegisterWindowsMessage MSDN को देखते हैं, सिद्धांत रूप में, एक रिवर्स अपंजीकृत कार्रवाई का अर्थ नहीं है, क्योंकि यह फ़ंक्शन कई कार्यक्रमों को एक साथ कुछ संदेश आईडी का उपयोग करने की अनुमति देता है:

RegisterWindowMessage फ़ंक्शन का उपयोग आमतौर पर दो सहयोगी अनुप्रयोगों के बीच संवाद स्थापित करने के लिए संदेशों को पंजीकृत करने के लिए किया जाता है।

यदि दो अलग-अलग अनुप्रयोग एक ही संदेश स्ट्रिंग को पंजीकृत करते हैं, तो अनुप्रयोग समान संदेश मान लौटाते हैं। सत्र समाप्त होने तक संदेश पंजीकृत रहता है ।

यह गंभीर है, क्योंकि हमारे पास स्थिति को प्रभावित करने का कोई लाभ नहीं है। तीसरे पक्ष के आवेदन के साथ इस तरह के परमाणु को बंद करना असंभव है - लेख में प्रस्तावित कार्यक्रम जिसने मुझे इस पोस्ट को लिखने के लिए प्रेरित किया वह यहां शक्तिहीन है। चूँकि परमाणु तालिका में 16 बिट युग में जड़ें होती हैं, जो तालिका के आकार पर एक सीमा लगाती है, यह कष्टप्रद बग बहुत जल्दी से सर्वर भाग को क्रम से बाहर कर देता है, क्योंकि सिस्टम को रिबूट किए बिना किसी भी डेल्फी एप्लिकेशन को लॉन्च करना संभव नहीं था।

यहाँ एक उदाहरण है कि परमाणु तालिका एक सामान्य कार्यक्रम के लिए "सामान्य शुरुआत-सही पूरा होने" के 20 पुनरावृत्तियों के बाद कैसा दिखता है: 1

लाल रंग में हाइलाइट किए गए परमाणु वे हैं जो केवल 20 लॉन्च के बाद बने रहे।

यह त्रुटि कई स्थानों पर वर्णित की गई है, उदाहरण के लिए:
विस्तृत त्रुटि विवरण
अधिक संक्षिप्त बग रिपोर्ट
अच्छी तरह से और, ढेर अतिप्रवाह

समाधान विधि

चूंकि परमाणु को पोस्ट-फैक्टम से हटाया नहीं जा सकता है, इसलिए इसके निर्माण को रोकना आवश्यक है। हमारी टीम ने एक IAT हुक का रास्ता अपनाया, जो RegisterWindowMessageA के लिए एक कॉल को इंटरसेप्ट करता है और अगर ControlOfs के नाम के साथ एक संदेश <कुछ वहां> लॉग किया गया है, तो कोई भी अन्य पहचानकर्ता जो सभी अनुप्रयोगों के लिए समान है, बजाय लॉग किया गया है। जैसा कि यह निकला, उसे अद्वितीय नहीं होना था, जो बग रिपोर्ट में भी इंगित किया गया है , जिसे मैंने पहले ही संदर्भित किया था ।

हुक कोड तुच्छ है, जैसा कि इसे स्थापित करने के लिए तंत्र है। इसके अलावा, इंटरनेट पर IAT हुक के लिए डेल्फी के लिए तैयार पुस्तकालय हैं। हुक खुद को केवल इतनी जल्दी जांच करता है कि क्या पंजीकृत किया जा रहा संदेश कंट्रोलऑफ उपसर्ग से मेल नहीं खाता है, और यदि ऐसा होता है, तो इसे RM_GetObjectInstance के साथ बदल दिया जाता है - एक समान पहचानकर्ता जो सभी अनुप्रयोगों के लिए समान है, मूल RegisterWindowMessage पर कॉल के साथ।

मुझे उम्मीद है कि यह किसी को लंबी और कठिन डिबगिंग से बचने में मदद करता है।