Topleaked: मेमोरी लीक को पकड़ने का एक उपकरण

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

विचार

मूल सेवा सी ++ और पर्ल में लिखी गई थी, हालांकि यह एक विशेष भूमिका नहीं निभाता है। नीचे वर्णित सब कुछ लगभग किसी भी भाषा पर लागू होता है।

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

Vtbl के अलावा, अन्य अक्सर होने वाले क्रम होते हैं: स्थिरांक जो फ़ील्ड को आरम्भ करते हैं, स्ट्रिंग हेडर में HTTP हेडर, फ़ंक्शन के लिए पॉइंटर्स।
यदि हम एक पॉइंटर खोजने के लिए पर्याप्त भाग्यशाली हैं, तो हम यह समझने के लिए gdb का उपयोग कर सकते हैं कि यह क्या इंगित करता है (जब तक कि निश्चित रूप से डिबेट वर्ण नहीं हैं)। डेटा के मामले में, आप उन्हें देखने और समझने की कोशिश कर सकते हैं कि यह कहाँ उपयोग किया जाता है। आगे देखते हुए, मैं ध्यान देता हूं कि ऐसा होता है कि दोनों और एक और, एक लाइन के टुकड़े से, यह समझना काफी संभव है कि प्रोटोकॉल का यह हिस्सा क्या है और आगे कहां खोदना है।

इस विचार की जासूसी की गई थी, और पहले कार्यान्वयन को स्पष्ट रूप से स्टैकओवरफ़्लो से कॉपी किया गया था। https://stackoverflow.com/questions/7439170/is-there-a-way-to-find-leaked-memory-using-a-core-file

hexdump core.10639 | awk '{printf "%s%s%s%s\n%s%s%s%s\n", $5,$4,$3,$2,$9,$8,$7,$6}' | sort | uniq -c | sort -nr | head 

स्क्रिप्ट ने हमारे डंप पर लगभग 15 मिनट तक काम किया, लाइनों का एक गुच्छा लौटाया, और ... कुछ भी नहीं। एक भी सूचक नहीं, उपयोगी कुछ भी नहीं।

छंटनी हुई

Stackoverflow- संचालित विकास में इसकी कमियां हैं। आप केवल स्क्रिप्ट की प्रतिलिपि नहीं बना सकते हैं और आशा करते हैं कि सब कुछ काम करेगा। इस विशेष लिपि में, बाइट्स के किसी प्रकार की पुनर्व्यवस्था तुरंत आंख को पकड़ लेती है। सवाल यह भी उठता है, क्यों 4 द्वारा क्रमपरिवर्तन। आपको यह समझने के लिए एक सुपर विशेषज्ञ होने की आवश्यकता नहीं है कि इस तरह के क्रमपरिवर्तन प्लेटफॉर्म पर निर्भर करते हैं: बिटनेस और बाइट ऑर्डर।

वास्तव में कैसे देखना है, यह समझने के लिए, आपको मेमोरी डंप, LITTLE- और BIG-endian के फ़ाइल प्रारूप को समझने की आवश्यकता है, या आप अलग-अलग तरीकों से पाए गए टुकड़ों में बाइट्स को पुनर्व्यवस्थित कर सकते हैं और जीडीबी दे सकते हैं। अरे चमत्कार! प्रत्यक्ष क्रम में, जीडीबी बाइट चरित्र को देखता है और कहता है कि यह एक फ़ंक्शन का सूचक है!

हमारे मामले में, यह ओपनसेल बफर में पढ़ने और लिखने के कार्यों में से एक के लिए एक संकेतक था। इनपुट और आउटपुट को अनुकूलित करने के लिए ओओपी सिस्टम दृष्टिकोण का उपयोग किया जाता है - एक संरचना जिसमें कार्यों के लिए एक बिंदु है, जो एक प्रकार का इंटरफ़ेस या बल्कि vtbl है। संकेत के साथ ये संरचनाएं बहुत से पागलपन वाली निकलीं। इन संरचनाओं को स्थापित करने और बफ़र्स बनाने के लिए जिम्मेदार कोड पर एक करीबी नज़र हमें जल्दी से त्रुटि खोजने की अनुमति देती है। जैसा कि यह निकला, सी ++ और सी के जंक्शन पर आरएआईआई ऑब्जेक्ट नहीं थे और त्रुटि की स्थिति में, शुरुआती रिटर्न ने संसाधनों को मुक्त करने का मौका नहीं छोड़ा। किसी ने समय पर गलत ssl हैंडशेक के साथ सेवा को लोड करने का अनुमान नहीं लगाया, इसलिए वे इससे चूक गए। गलत ssl हैंडशेक के 6 गीगाबाइट कैसे डायल करें यह भी दिलचस्प है, लेकिन जैसा कि वे कहते हैं, यह एक पूरी तरह से अलग कहानी है। समस्या हल हो गई है।

topleaked

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

स्थापना

कोई बाइनरी असेंबलियां नहीं हैं, इसलिए एक तरह से या किसी अन्य को आपको स्रोत से प्रोजेक्ट को इकट्ठा करने की आवश्यकता होगी। ऐसा करने के लिए, आपको डी कंपाइलर की आवश्यकता है। तीन विकल्प हैं: dmd संदर्भ संकलक है, ldc llvm और gdc पर आधारित है, जिसे gcc में शामिल किया गया है, जो संस्करण 9 से शुरू होता है। यदि आपके पास नवीनतम gcc है तो आपको कुछ भी स्थापित करने की आवश्यकता नहीं है। यदि आप स्थापित करते हैं, तो मैं ldc की सलाह देता हूं, क्योंकि यह बेहतर अनुकूलन करता है। इन तीनों को आधिकारिक वेबसाइट पर पाया जा सकता है।
डब पैकेज मैनेजर को कंपाइलर के साथ आपूर्ति की जाती है। इसका उपयोग करते हुए, एक आदेश के साथ topleaked स्थापित किया गया है:

 dub fetch topleaked 

भविष्य में, हम शुरू करने के लिए कमांड का उपयोग करेंगे:

 dub run topleaked -brelease-nobounds -- <filename> [<options>...] 

डब रन और brelease-nobounds संकलक तर्क को दोहराने के लिए नहीं, आप गीथूब से स्रोतों को डाउनलोड कर सकते हैं और निष्पादन योग्य फ़ाइल एकत्र कर सकते हैं:

 dub build -brelease-nobounds 

प्रोजेक्ट के रूट में फ़ोल्डर टोलपेक दिखाई देगा।

के उपयोग

चलो स्मृति रिसाव के साथ एक सरल सी ++ प्रोग्राम लेते हैं।

 #include <iostream> #include <assert.h> #include <unistd.h> class A { size_t val = 12345678910; virtual ~A(){} }; int main() { for (size_t i =0; i < 1000000; i++) { new A(); } std::cout << getpid() << std::endl; sleep(200); } 

हम इसे मार -6 के माध्यम से पूरा करते हैं, जबकि हमें मेमोरी डंप मिलती है। अब आप topleaked चला सकते हैं और परिणाम देख सकते हैं

 ./toleaked -n10 leak.core 

-N विकल्प उस शीर्ष का आकार है जिसकी हमें आवश्यकता है। आमतौर पर, 10 और 200 के बीच का मूल्य समझ में आता है, यह निर्भर करता है कि "कचरा" कितना है। डिफ़ॉल्ट आउटपुट स्वरूप मानव-पठनीय रूप में एक पंक्ति-दर-पंक्ति शीर्ष है।

 0x0000000000000000 : 1050347 0x0000000000000021 : 1000003 0x00000002dfdc1c3e : 1000000 0x0000558087922d90 : 1000000 0x0000000000000002 : 198 0x0000000000000001 : 180 0x00007f4247c6a000 : 164 0x0000000000000008 : 160 0x00007f4247c5c438 : 153 0xffffffffffffffff : 141 

यह बहुत कम उपयोग है, सिवाय इसके कि हम संख्या 0x2dfdc1c3e देख सकते हैं, जो कि 12345678910 भी है, जो एक लाख बार होता है। पहले से ही यह पर्याप्त हो सकता है, लेकिन मैं और अधिक चाहता हूं। लीक की गई वस्तुओं के वर्ग नामों को देखने के लिए, आप एक खुले डंप फ़ाइल के साथ gdb इनपुट के लिए मानक आउटपुट स्ट्रीम को केवल पुनर्निर्देशित करके जीडीबी को परिणाम भेज सकते हैं। -ogdb - विकल्प को समझने योग्य gdb में प्रारूप बदलना।

 $ ./topleaked -n10 -ogdb /home/core/leak.1002.core | gdb leak /home/core/leak.1002.core ...<   gdb  > #0 0x00007f424784e6f4 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcfffedb50, remaining=remaining@entry=0x7ffcfffedb50) at ../sysdeps/unix/sysv/linux/nanosleep.c:28 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory. (gdb) $1 = 1050347 (gdb) 0x0: Cannot access memory at address 0x0 (gdb) No symbol matches 0x0000000000000000. (gdb) $2 = 1000003 (gdb) 0x21: Cannot access memory at address 0x21 (gdb) No symbol matches 0x0000000000000021. (gdb) $3 = 1000000 (gdb) 0x2dfdc1c3e: Cannot access memory at address 0x2dfdc1c3e (gdb) No symbol matches 0x00000002dfdc1c3e. (gdb) $4 = 1000000 (gdb) 0x558087922d90 <_ZTV1A+16>: 0x87721bfa (gdb) vtable for A + 16 in section .data.rel.ro of /home/g.smorkalov/dlang/topleaked/leak (gdb) $5 = 198 (gdb) 0x2: Cannot access memory at address 0x2 (gdb) No symbol matches 0x0000000000000002. (gdb) $6 = 180 (gdb) 0x1: Cannot access memory at address 0x1 (gdb) No symbol matches 0x0000000000000001. (gdb) $7 = 164 (gdb) 0x7f4247c6a000: 0x47ae6000 (gdb) No symbol matches 0x00007f4247c6a000. (gdb) $8 = 160 (gdb) 0x8: Cannot access memory at address 0x8 (gdb) No symbol matches 0x0000000000000008. (gdb) $9 = 153 (gdb) 0x7f4247c5c438 <_ZTVN10__cxxabiv120__si_class_type_infoE+16>: 0x47b79660 (gdb) vtable for __cxxabiv1::__si_class_type_info + 16 in section .data.rel.ro of /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) $10 = 141 (gdb) 0xffffffffffffffff: Cannot access memory at address 0xffffffffffffffff (gdb) No symbol matches 0xffffffffffffffff. (gdb) quit 

पढ़ना बहुत सरल नहीं है, लेकिन संभव है। फॉर्म की पंक्तियाँ $ 4 = 1,000,000 शीर्ष में स्थिति और पाए जाने वाली घटनाओं की संख्या को दर्शाती हैं। नीचे मान के लिए x और जानकारी प्रतीक चलाने के परिणाम हैं। यहाँ हम देख सकते हैं कि A के लिए व्यवहार्य एक लाख बार होता है, जो कक्षा A की एक लाख लीक्ड वस्तुओं से मेल खाता है।

फ़ाइल के भाग का विश्लेषण करने के लिए (यदि यह बहुत बड़ा है), ऑफसेट और सीमा विकल्प जोड़े जाते हैं - जहां से और कितने बाइट्स पढ़ने के लिए शुरू होते हैं।

परिणाम

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

-Ddb विकल्प के लिए धन्यवाद और gdb में पुनर्निर्देशन, हम तुरंत नाम और मान प्राप्त करते हैं, कभी-कभी पंक्ति संख्या भी, यदि हम फ़ंक्शन के लिए भाग्यशाली हैं।

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

D भाषा

मैं डी में इस तरह के एक कार्यक्रम को विकसित करने के अनुभव को अलग से नोट करना चाहूंगा। पहला कार्य संस्करण कुछ ही मिनटों में लिखा गया था। मुझे कहना होगा कि अब तक मुख्य एल्गोरिथ्म केवल तीन लाइनें लेता है:

 auto all = input.sort; ValCount[] res = new ValCount[min(all.length, maxSize)]; return all.group.map!((p) => ValCount(p[0],p[1])) .topNCopy!"a.count>b.count"(res, Yes.sortOutput); 

सभी आलसी श्रेणियों के लिए धन्यवाद और मानक पुस्तकालय में उन पर तैयार एल्गोरिदम की उपस्थिति, जैसे समूह और टॉपएन।

बाद में, कमांड लाइन के तर्कों की पार्सिंग, आउटपुट का प्रारूपण, और सब कुछ जो क्रिया है, लेकिन जल्दी से लिखा गया है, शीर्ष पर विकसित हुआ। जब तक फ़ाइल का पठन सामान्य शैली से बाहर किसी तरह से अजीब नहीं हो जाता।

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

कुल मिलाकर, श्रम लागत स्क्रिप्टिंग भाषाओं के लिए तुलनीय है, और प्रदर्शन में बहुत बेहतर है। संभावित रूप से, आप इसे अधिकतम संभव तक ला सकते हैं, क्योंकि C और D में समान कोड समान गति से समान काम करेंगे।

संकेत और उपयोग के लिए मतभेद

• Topleaked को लीक की खोज करने की आवश्यकता होती है जब वर्तमान प्रक्रिया की मेमोरी का केवल एक डंप होता है, लेकिन सैनिटाइज़र के तहत इसे पुन: पेश करने का कोई तरीका नहीं है।
• यह एक और वैध नहीं है और गतिशील विश्लेषण का दावा नहीं करता है।
• पिछली टिप्पणी का एक दिलचस्प अपवाद अस्थायी लीक हो सकता है। यही है, मेमोरी को मुक्त किया गया है, लेकिन बहुत देर हो चुकी है (जब सर्वर बंद हो जाता है, उदाहरण के लिए)। फिर आप सही समय पर डंप को हटा सकते हैं और विश्लेषण कर सकते हैं। वैलग्रिंड या आसन, प्रक्रिया के समाप्त होने के समय काम करना, इसे और भी बदतर कर सकता है।
• केवल 64-बिट मोड। अन्य बिट्स और बाइट ऑर्डर के लिए समर्थन भविष्य के लिए स्थगित कर दिया गया है।

ज्ञात मुद्दे

परीक्षण के दौरान, डंप फ़ाइलों का उपयोग किया गया था जो प्रक्रिया को संकेत भेजकर प्राप्त किए गए थे। ऐसी फ़ाइलों के साथ, सब कुछ अच्छी तरह से काम करता है। जब एक डंप हटा दिया जाता है, तो gcore कमांड कुछ अन्य ELF हेडर लिखता है और एक अनिश्चित संख्या में बाइट्स की भरपाई होती है। यही है, पॉइंटर्स के मान फ़ाइल में 8 से संरेखित नहीं होते हैं, इसलिए अर्थहीन परिणाम प्राप्त होते हैं। समाधान के लिए, ऑफसेट विकल्प पेश किया गया था - फ़ाइल को पहले नहीं पढ़ने के लिए, लेकिन ऑफसेट बाइट्स (आमतौर पर 4) द्वारा स्थानांतरित किया गया।
इसे हल करने के लिए, मैं स्टड से objdump -s के परिणाम पढ़ने को जोड़ने की योजना बना रहा हूं। ठीक है, या तो परिवाद को कनेक्ट करें और इसे स्वयं पार्स करें, लेकिन यह "क्रॉस-प्लेटफॉर्म" को मार देगा, और स्टडआउट अधिक लचीला और यूनिक्स रास्ते के करीब है।

संदर्भ

जीथब प्रोजेक्ट
संकलक डी
स्टैकओवरफ्लो पर मूल प्रश्न