👩🏿‍🎤 🛑 ↩️ GDI लीक और भाग्य के महत्व के बारे में 🙏 🌦️ 🐆

मई 2019 में, मुझे संभावित खतरनाक क्रोम बग पर एक नज़र डालने के लिए कहा गया था। सबसे पहले, मैंने उसे महत्वहीन समझा, इस तरह से दो सप्ताह बर्बाद कर दिए। बाद में, जब मैं जांच करने के लिए लौटा, तो यह क्रोम बीटा चैनल में ब्राउज़र प्रक्रिया के क्रैश होने के कारण नंबर एक में बदल गया। उफ़

6 जून, उसी दिन जब मुझे प्रस्थान के डेटा की व्याख्या करने में अपनी गलती का एहसास हुआ, बग को रिलीजब्लॉक-स्टेबल के रूप में चिह्नित किया गया था। इसका मतलब है कि जब तक हम यह पता नहीं लगा लेते कि हम अधिकांश उपयोगकर्ताओं के लिए Chrome का एक नया संस्करण जारी नहीं कर सकते, तब तक हम क्या करेंगे।

क्रैश इसलिए होता है क्योंकि हम GDI ऑब्जेक्ट्स (ग्राफ़िक्स डिवाइस इंटरफ़ेस) से बाहर चल रहे थे , लेकिन हमें नहीं पता था कि वे किस प्रकार की GDI ऑब्जेक्ट्स हैं, डायग्नोस्टिक डेटा ने समस्या के बारे में कोई सुराग नहीं दिया था, और हम इसे फिर से नहीं बना सके।

हमारी टीम के कई लोगों ने 6-7 जून को इस बग पर कड़ी मेहनत की, उन्होंने अपने सिद्धांतों का परीक्षण किया, लेकिन आगे नहीं बढ़े। 8 जून को, मैंने अपने मेल की जांच करने का फैसला किया और क्रोम तुरंत दुर्घटनाग्रस्त हो गया। यह वही असफलता थी ।

कैसी विडंबना। जब मैं परिवर्तनों की खोज कर रहा था और क्रैश रिपोर्ट की जांच कर रहा था, तो यह पता लगाने की कोशिश कर रहा था कि GDI ऑब्जेक्ट्स लीक करने के लिए Chrome ब्राउज़र प्रक्रिया क्या हो सकती है, मेरे ब्राउज़र में GDI ऑब्जेक्ट्स की संख्या में लगातार वृद्धि हो रही थी, और 8 जून की सुबह तक यह जादुई संख्या 10,000 से अधिक हो गई । इस बिंदु पर, GDI ऑब्जेक्ट के लिए मेमोरी आवंटन कार्यों में से एक विफल हो गया और हमने जानबूझकर ब्राउज़र को क्रैश कर दिया। यह एक अविश्वसनीय भाग्य था।

यदि आप बग को पुन: पेश कर सकते हैं, तो अनिवार्य रूप से आप इसे ठीक कर सकते हैं। मुझे सिर्फ यह पता लगाना था कि मैंने इस बग का कारण कैसे बनाया, जिसके बाद हम इसे खत्म कर सकते हैं।

शुरू करने के लिए, एक छोटा इतिहास

क्रोमियम कोड के अधिकांश स्थानों में, जब हम GDI ऑब्जेक्ट के लिए मेमोरी आवंटित करने का प्रयास करते हैं, तो हम पहले जांचते हैं कि क्या यह आवंटन सफल था। यदि मेमोरी को आवंटित करना संभव नहीं था, तो हम स्टैक पर कुछ जानकारी लिखते हैं और जानबूझकर क्रैश करते हैं, जैसा कि इस स्रोत कोड में देखा जा सकता है । विफलता जानबूझकर उत्पन्न होती है, क्योंकि यदि हम GDI ऑब्जेक्ट्स के लिए मेमोरी आवंटित नहीं कर सकते हैं, तो हम स्क्रीन पर रेंडर नहीं कर पाएंगे - किसी समस्या की रिपोर्ट करना बेहतर है (यदि क्रैश रिपोर्ट सक्षम हैं) और खाली UI प्रदर्शित करने की तुलना में प्रक्रिया को पुनरारंभ करें। डिफ़ॉल्ट रूप से, आप प्रति प्रक्रिया 10,000 GDI ऑब्जेक्ट बना सकते हैं, और आमतौर पर केवल कुछ सौ का उपयोग किया जाता है। इसलिए, अगर हम इस सीमा को पार कर गए, तो कुछ पूरी तरह से गलत हो गया।

जब हमें क्रैश रिपोर्ट में से एक मिलता है जो GDI ऑब्जेक्ट के लिए मेमोरी आवंटन त्रुटि के बारे में कहता है, तो हमारे पास कॉल स्टैक और अन्य उपयोगी जानकारी के सभी प्रकार हैं। ठीक! लेकिन समस्या यह है कि इस तरह के क्रैश डंप बग से संबंधित नहीं हैं। ऐसा इसलिए है क्योंकि GDI ऑब्जेक्ट्स के रिसाव का कारण बनने वाला कोड और विफलता की रिपोर्ट करने वाला कोड समान कोड नहीं हो सकता है।

यानी मोटे तौर पर, हमारे पास दो प्रकार के कोड हैं:

शून्य गुडकोड () {
   ऑटो एक्स = एलोकेटगाइडबोजेक्ट ();
   अगर (x)
     कलेक्टजीडीयूजेजएंडी ();
   UseGDIObject (x);
   FreeGDIObject (x);
}

शून्य बैडकोड () {
   ऑटो एक्स = एलोकेटगाइडबोजेक्ट ();
   UseGDIObject (x);
}

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

क्रोमियम में कोड की कई मिलियन लाइनें होती हैं। हमें नहीं पता था कि किस फ़ंक्शन में त्रुटि थी, और यह भी नहीं पता था कि किस प्रकार की GDI ऑब्जेक्ट लीक हो रही थीं । मेरे एक साथी ने प्रत्येक प्रकार के GDI ऑब्जेक्ट्स की संख्या प्राप्त करने के लिए क्रैश से पहले प्रोसेस एनवायरनमेंट ब्लॉक को बायपास किया , लेकिन सभी एन्यूमरेटेड प्रकारों (डिवाइस संदर्भों, क्षेत्रों, बिटमैप्स, पैलेट्स, ब्रश, पंख और अज्ञात) के लिए संख्या एक सौ से अधिक नहीं थी। यह बहुत अजीब है।

यह पता चला कि जिन वस्तुओं के लिए हम सीधे मेमोरी आवंटित करते हैं वे इस तालिका में हैं, लेकिन हमारी ओर से कर्नेल द्वारा बनाई गई कोई भी वस्तु नहीं है, और वे विंडोज ऑब्जेक्ट मैनेजर में कहीं मौजूद हैं। इसका मतलब यह था कि GDIView इस समस्या के लिए उतना ही अंधा है जितना कि हम हैं (इसके अलावा, GDIView केवल तभी उपयोगी है जब दुनिया भर में विफलता हो)। क्योंकि हमने कर्सर को लीक कर दिया है, और कर्सर USER32 ऑब्जेक्ट्स हैं जिनके साथ GDI ऑब्जेक्ट्स जुड़ी हुई हैं; इन GDI ऑब्जेक्ट्स के लिए मेमोरी कर्नेल द्वारा आवंटित की जाती है, और हम यह नहीं देख पाए कि क्या हो रहा था।

अशुद्ध अर्थ

हमारे फ़ंक्शन CollectGDIUsageAndDie का एक बहुत ही ज्वलंत नाम है, और मुझे लगता है कि आप इस पर मेरे साथ सहमत होंगे। बहुत भावबोधक।

समस्या यह है कि यह बहुत सारी क्रियाएं करता है। CollectGDIUsageAndDie ने GDI ऑब्जेक्ट्स के लिए लगभग एक दर्जन विभिन्न प्रकार की मेमोरी आवंटन विफलताओं की जाँच की, और कोड के एम्बेड करने के कारण, उन्हें एक ही विफलता हस्ताक्षर प्राप्त हुआ - परिणामस्वरूप वे सभी मुख्य कार्यों में क्रैश हो गए और एक साथ विलय हो गए। इसलिए, मेरे एक सहकर्मी ने समझदारी से एक बदलाव किया , अलग-अलग चेक को अलग-अलग (बिल्ट-इन) कार्यों में नहीं तोड़ दिया । इसके लिए धन्यवाद, अब, पहली नज़र में, हम समझ सकते हैं कि कौन सा चेक विफलता में समाप्त हुआ।

काश, यह इस तथ्य की ओर ले जाता कि जब हमें CrashIfExcessiveHandles से क्रैश रिपोर्ट मिलनी शुरू हुई, मैंने आत्मविश्वास से कहा: "यह विफलता का कारण नहीं है, यह केवल हस्ताक्षर में बदलाव के कारण होता है।"

पर मैं गलत था। यह विफलता और हस्ताक्षर परिवर्तन का कारण था । उफ़ अजीब विश्लेषण, डॉसन। आपके लिए कोई कुकीज़ नहीं।

हमारी कहानी पर वापस

इस बिंदु पर, मुझे पहले से ही पता था कि 7 जून को मैंने जो कुछ किया था वह प्रति दिन लगभग 10,000 जीडीआई वस्तुओं का उपयोग करता था। अगर मैं यह समझ सकता था कि मैं पहेली को हल करूंगा।

विंडोज टास्क मैनेजर में एक अतिरिक्त GDI ऑब्जेक्ट कॉलम है जिसका उपयोग आप लीक खोजने के लिए कर सकते हैं। 7 जून को, मैं घर से काम कर रहा था, अपनी कार्य मशीन से जुड़ रहा था, और यह कॉलम काम मशीन पर चालू हो गया था क्योंकि मैंने परीक्षण चलाए और क्रैश परिदृश्य को पुन: पेश करने की कोशिश की। लेकिन इस बीच, मेरे होम मशीन पर ब्राउज़र में GDI ऑब्जेक्ट्स के लीक थे।

मुख्य कार्य जिसके लिए मैंने घर पर ब्राउज़र का उपयोग किया था वह क्रोम रिमोट डेस्कटॉप (सीआरडी) एप्लिकेशन का उपयोग करके एक कार्यशील मशीन से जुड़ना है । इसलिए मैंने घरेलू मशीन पर GDI ऑब्जेक्ट्स कॉलम को चालू किया और प्रयोग करना शुरू कर दिया। जल्द ही मुझे परिणाम मिल गए।

वास्तव में, बग की समयावधि यह दर्शाती है कि जिस क्षण से "मुझे असफलता मिली थी" (14:00) से "यह किसी तरह सीआरडी से जुड़ा हुआ है", और फिर "कर्सर में मामला" केवल 35 मिनट बीत गए। मैंने पहले ही कहा है कि बगों की जांच करना कितना आसान है जब आप उन्हें स्थानीय स्तर पर खेल सकते हैं?

यह पता चला कि हर बार एक सीआरडी एप्लिकेशन (या किसी भी क्रोम एप्लिकेशन?) को बदल दिया गया था, इससे छह जीडीआई वस्तुओं का रिसाव हुआ। यदि आप क्रोम रिमोट डेस्कटॉप के साथ काम करते समय माउस को स्क्रीन के इच्छित भाग पर ले जाते हैं, तो प्रति मिनट सैकड़ों GDI ऑब्जेक्ट और प्रति घंटे हजारों रिसाव हो सकते हैं।

इस समस्या को हल करने में किसी भी प्रगति की अनुपस्थिति के एक महीने के बाद, यह अचानक एक साधारण सुधार में बदल गया। मैंने जल्दी से एक ड्राफ्ट फिक्स लिखा, और फिर मेरे एक साथी (मैंने इस बग पर काम नहीं किया) ने एक वास्तविक फिक्स बनाया। इसे 10 जून को 11:16 बजे डाउनलोड किया गया था, और 13:00 बजे जारी किया गया था। कुछ मर्जों के बाद, बग गायब हो गया।

बस इतना ही?

हमने बग को ठीक कर दिया है, और यह बहुत अच्छा है, लेकिन यह अधिक महत्वपूर्ण है कि इस तरह के कीड़े फिर कभी न हों। जाहिर है, संसाधन प्रबंधन के लिए C ++ ( RAII ) ऑब्जेक्ट्स का उपयोग करना सही है , लेकिन इस मामले में बग को WebCursor वर्ग में समाहित किया गया था।

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

पीईबी को अस्पष्ट रूप से पढ़ने के बिना (और कर्सर को अनदेखा किए बिना) सभी प्रकार की जीडीआई वस्तुओं की संख्या को तुच्छ बनाने की प्रक्रिया करें।
विश्वसनीय ट्रैकिंग के लिए GDI ऑब्जेक्ट बनाने और नष्ट करने के सभी कार्यों को अवरोधन और ट्रेस करने के लिए एक समर्थित तरीका बनाएं ; उन लोगों के लिए जो अप्रत्यक्ष रूप से बनाए गए थे
प्रलेखन में यह सब प्रतिबिंबित करें

बस इतना ही। इस तरह की ट्रैकिंग को लागू करना भी मुश्किल नहीं है, क्योंकि जीडीआई वस्तुएं आवश्यक रूप से इस तरह से सीमित हैं कि स्मृति सीमित नहीं है। इन अजीब लेकिन अपरिहार्य GDI वस्तुओं का उपयोग करना सुरक्षित होगा तो बहुत अच्छा होगा। ओह कृपया।

यहां आप रेडिट पर चर्चा पढ़ सकते हैं। ट्विटर पर विषय यहीं से शुरू होता है ।

GDI लीक और भाग्य के महत्व के बारे में

शुरू करने के लिए, एक छोटा इतिहास

अशुद्ध अर्थ

हमारी कहानी पर वापस

बस इतना ही?

More articles: