👋🏽 🤵🏽 🕙 सी / सी ++ कार्यक्रमों में मेमोरी लीक

कई मेमोरी लीक मुद्दों की कहानियां। इनमें से अधिकांश समस्याएं काफी तुच्छ हैं, पुन: पेश करना आसान है, आसानी से उपयुक्त उपकरणों द्वारा पता लगाया जाता है, और तय किया जाता है। लेकिन, कई बार, समस्याएं असामान्य होती हैं, और एक असामान्य दृष्टिकोण या समाधान की आवश्यकता होती है ...

कोड लॉस मेमोरी

क्यूए में एक अन्य परीक्षण में उत्पाद के नए संस्करण में लोड के तहत एक छोटे से स्थायी स्मृति रिसाव का पता चला। प्लेबैक एक समस्या नहीं थी, लेकिन वालग्रिंड के तहत कार्यक्रम के शुरुआती दौर में किसी भी लीक का खुलासा नहीं हुआ।

कुछ विचार के बाद, विकल्प - लीक-चेक = पूर्ण चालू कर दिया गया और Valgrind ने लीक की रिपोर्ट करना शुरू कर दिया। लेकिन विभिन्न प्रकार के स्थिर चर की अनुमानित लीक के बीच, अक्सर जानबूझकर जारी नहीं किया गया था, रिसाव जैसा कुछ भी नहीं था। आमतौर पर, कई हजार पुनरावृत्तियों को चलाने के दौरान, मॉलोक द्वारा आवंटित खोई हुई मेमोरी ब्लॉकों की समान संख्या को आवंटित करना आसान होता है। इस मामले में, 10,000 सर्वर अनुरोधों पर रिसाव न्यूनतम था।

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

==15882== 76,400 bytes in 8 blocks are definitely lost in loss record 2 of 3 
      

        
        
        
      

     ==15882==      at 0x401B007: operator new(unsigned int) (vg_replace_malloc.c:214) 
      

        
        
        
      

     ==15882==      by 0x40A40F0: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int&) (in /usr/lib/libstdc++.so.5.0.3) 
      

        
        
        
      

     ==15882==      by 0x40A3FFC: std::__default_alloc_template<true, 0>::_S_refill(unsigned int) (in /usr/lib/libstdc++.so.5.0.3) 
      

        
        
        
      

     ==15882==      by 0x40A3B6B: std::__default_alloc_template<true, 0>::allocate(unsigned int) (in /usr/lib/libstdc++.so.5.0.3) 
      

        
        
        
      

     ==15882==      by 0x40A9B67: std::string::_Rep::_S_create(unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.3) 
      

        
        
        
      

     ==15882==      by 0x40A9C98: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) (in /usr/lib/libstdc++.so.5.0.3) 
      

        
        
        
      

     ==15882==      by 0x40A7A05: std::string::reserve(unsigned int) (in /usr/lib/libstdc++.so.5.0.3) 
      

        
        
        
      

     ==15882==      by 0x8049826: std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, 
      

        
        
        
      

     std::char_traits<char>, std::allocator<char> >(char const*, std::basic_string<char, std::char_traits<char>, 
      

        
        
        
      

     std::allocator<char> > const&) (basic_string.tcc:619) 
      

        
        
        
      

     ==15882==      by 0x804956A: A::A(A const&) (class_a.cpp:20) 
      

        
        
        
      

     ==15882==      by 0x80491BC: foo(int) (test.cpp:23) 
      

        
        
        
      

     ==15882==      by 0x80492EA: main (test.cpp:32)

ऐसा लगता है कि स्मृति रिसाव का स्रोत मिल गया था, लेकिन कोड बिल्कुल निर्दोष लग रहा था - एक फ़ंक्शन कॉल जो उस पर पारित ऑब्जेक्ट की एक अस्थायी प्रतिलिपि के साथ है:

doSomething( condition ? Object( params ) : getObject() );

हम पहले से ही सुनिश्चित थे कि मेमोरी इस लाइन में खो गई थी, और इस लाइन के लिए संकलक द्वारा उत्पन्न कोड को देखना शुरू किया। सब कुछ जगह में लग रहा था - "basic_string :: लंबाई ()", हालत की एक शाखा के लिए पैरामीटर वर्ग के निर्माता के लिए एक कॉल, "पैरेंट :: getB ()" के लिए एक कॉल और दूसरी शाखा के लिए एक कॉपी कंस्ट्रक्टर, फ़ंक्शन "A ::" के लिए एक कॉल। बनाएँ ", अस्थायी वस्तुओं की रिहाई - वर्ग की एक अस्थायी प्रतिलिपि के विध्वंसक को छोड़कर सब कुछ - स्टैक पर बनाई गई है, लेकिन अंदर स्ट्रिंग की एक प्रति शामिल है, जिसके परिणामस्वरूप मुक्त नहीं किया गया था!

 110: return A::create(b1, b2, s.length() > 0 ? B(s) : getB()); 13d4: 83 ec 0c sub $0xc,%esp 13d7: 8d 45 d8 lea 0xffffffd8(%ebp),%eax 13da: 50 push %eax 13db: e8 fc ff ff ff call std::basic_string<wchar_t>::length() const <<========= 13e0: 83 c4 10 add $0x10,%esp 13e3: 85 c0 test %eax,%eax 13e5: 74 18 je 13ff <A::create+0x341> 13e7: 83 ec 08 sub $0x8,%esp 13ea: 8d 45 d8 lea 0xffffffd8(%ebp),%eax 13ed: 50 push %eax 13ee: 8d 85 f8 fe ff ff lea 0xfffffef8(%ebp),%eax 13f4: 50 push %eax 13f5: e8 fc ff ff ff call B::B( std::basic_string<wchar_t> const & ) <<========= 13fa: 83 c4 10 add $0x10,%esp 13fd: eb 21 jmp 1420 <A::create+0x362> 13ff: 83 ec 08 sub $0x8,%esp 1402: 83 ec 04 sub $0x4,%esp 1405: ff 75 0c pushl 0xc(%ebp) 1408: e8 fc ff ff ff call Parent::getB() <<========= 140d: 83 c4 08 add $0x8,%esp 1410: 50 push %eax 1411: 8d 85 f8 fe ff ff lea 0xfffffef8(%ebp),%eax 1417: 50 push %eax 1418: e8 fc ff ff ff call B::B( B const & ) <<========= 141d: 83 c4 10 add $0x10,%esp 1420: 83 ec 0c sub $0xc,%esp 1423: 8d 85 f8 fe ff ff lea 0xfffffef8(%ebp),%eax 1429: 50 push %eax 142a: 0f b6 45 f6 movzbl 0xfffffff6(%ebp),%eax 142e: 50 push %eax 142f: 0f b6 45 f7 movzbl 0xfffffff7(%ebp),%eax 1433: 50 push %eax 1434: ff 75 0c pushl 0xc(%ebp) 1437: ff 75 08 pushl 0x8(%ebp) 143a: e8 fc ff ff ff call A::create(bool, bool, B) <<========= 143f: 83 c4 1c add $0x1c,%esp 1442: 83 ec 0c sub $0xc,%esp 1445: 8d 85 68 ff ff ff lea 0xffffff68(%ebp),%eax 144b: 50 push %eax 144c: e8 fc ff ff ff call BS<100, char>::~BS() 1451: 83 c4 10 add $0x10,%esp 1454: 83 ec 0c sub $0xc,%esp 1457: 8d 45 d8 lea 0xffffffd8(%ebp),%eax 145a: 50 push %eax 145b: e8 fc ff ff ff call std::basic_string<wchar_t>::~basic_string() 1460: 83 c4 10 add $0x10,%esp 1463: eb 55 jmp 14ba <A::create+0x3fc> 1465: 89 85 f0 fe ff ff mov %eax,0xfffffef0(%ebp) 146b: 8b b5 f0 fe ff ff mov 0xfffffef0(%ebp),%esi 1471: 83 ec 0c sub $0xc,%esp 1474: 8d 85 68 ff ff ff lea 0xffffff68(%ebp),%eax 147a: 50 push %eax 147b: e8 fc ff ff ff call BS<100, char>::~BS() 1480: 83 c4 10 add $0x10,%esp 1483: 89 b5 f0 fe ff ff mov %esi,0xfffffef0(%ebp) 1489: eb 06 jmp 1491 <A::create+0x3d3> 148b: 89 85 f0 fe ff ff mov %eax,0xfffffef0(%ebp) 1491: 8b b5 f0 fe ff ff mov 0xfffffef0(%ebp),%esi 1497: 83 ec 0c sub $0xc,%esp 149a: 8d 45 d8 lea 0xffffffd8(%ebp),%eax 149d: 50 push %eax 149e: e8 fc ff ff ff call std::basic_string<wchar_t>::~basic_string() 14a3: 83 c4 10 add $0x10,%esp 14a6: 89 b5 f0 fe ff ff mov %esi,0xfffffef0(%ebp) 14ac: 83 ec 0c sub $0xc,%esp 14af: ff b5 f0 fe ff ff pushl 0xfffffef0(%ebp) 14b5: e8 fc ff ff ff call _Unwind_Resume

कोड को डिस्ट्रॉक्टर कॉल कभी नहीं मिला, उन्होंने समान समस्याओं की तलाश शुरू कर दी, और लगभग तुरंत " जीसीसी 3.2 बग 9946 - ऑब्जेक्ट डिस्ट्रक्टर को नहीं बुलाया गया, संभवतः एक मेमोरी लीक का कारण बना "।

समस्या "?:" ऑपरेटर के लिए कोड उत्पन्न करने के लिए थी, और संकलक को अद्यतन करके या "?:" ऑपरेटर के लिए एक सरल अगर () द्वारा हल किया गया था।

//  ,      
      

        
        
        
      

     const Object & getObject(); 
      

        
        
        
      

     
      

        
        
        
      

     //       
      

        
        
        
      

     void doSomething( Object obj ); 
      

        
        
        
      

     
      

        
        
        
      

     //    ,    . 
      

        
        
        
      

     //          , 
      

        
        
        
      

     //          . 
      

        
        
        
      

     doSomething( condition ? Object( params ) : getObject() );

एक साधारण परीक्षण कार्यक्रम निम्नलिखित को आउटपुट करेगा (वर्ग ए की संख्याओं को ध्यान में रखते हुए और मुक्त किया गया):

main() start 
      

        
        
        
      

     A::A( 'on stack' ) 
      

        
        
        
      

     B::B() 
      

        
        
        
      

     A::A( 'static instance' ) 
      

        
        
        
      

     A::A( 'copy of static instance' ) 
      

        
        
        
      

     B::boo() 
      

        
        
        
      

     B::~B() 
      

        
        
        
      

     A::~A( 'on stack' ) 
      

        
        
        
      

     main() end 
      

        
        
        
      

     A::~A( 'static instance' ) 
      

        
        
        
      

     Class A created 3 times and destroyed 2 times 
      

        
        
        
      

     Class B created 1 times and destroyed 1 times

समस्या केवल तब हुई जब gcc 3.2.3 में 32-बिट कोड जनरेट किया गया और 64-बिट कोड या कंपाइलर के बाद के संस्करणों द्वारा उत्पन्न कोड में नहीं हुआ।

मैं मैं नहीं हूं, और मेरी स्मृति मेरी नहीं है

एक बार मैंने डेटा एकत्र करने और उन्हें सर्वर पर स्थानांतरित करने के लिए एक कार्यक्रम का समर्थन और अंतिम रूप दिया। इस कार्यक्रम ने लिनक्स सहित एक दर्जन प्लेटफार्मों पर काम किया। चूंकि यह कार्यक्रम वाणिज्यिक था, इसलिए इसे लिनक्स के न्यूनतम समर्थित संस्करण के अनुरूप कंपाइलर द्वारा संकलित किया गया था, हमारे मामले में gcc 3.3.x, और निष्पादन योग्य फाइलें प्रदान की गई थीं।

एक बिंदु पर, हमारे क्यूए विभाग ने पंजीकृत किया और यहां तक कि पुन: पेश करने में कामयाब रहा (एक लंबे, कई दिनों के दौरान, भारी भार के तहत परीक्षण) स्मृति की कमी के कारण एक कार्यक्रम दुर्घटना - प्रक्रिया 3 जीबी मेमोरी खाती है और सफलतापूर्वक क्रैश होती है, उसी आकार का एक कोर डंप बनाता है। इसके अलावा, मेमोरी उपयोग में विस्फोटक वृद्धि शाब्दिक रूप से दुखद अंत से 10-15 मिनट पहले हुई, और उस समय प्रोसेसर लोड लगभग 12% था (सर्वर पर 4 दोहरे कोर प्रोसेसर थे, इसलिए एक चक्र में एक धागा कताई का उपयोग करना चाहिए 12.5%)।

ड्रॉप किए गए धागे के कॉल स्टैक ने कॉपी कंस्ट्रक्टर में पूरी तरह से तुच्छ कोड को इंगित किया, यह केवल स्पष्ट था कि यह किसी तरह असाधारण स्थितियों से जुड़ा था।

 (gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb7dbd8d0 in raise () from /lib/libc.so.6 #2 0xb7dbeff3 in abort () from /lib/libc.so.6 #3 0xb7f86da5 in dlopen () from /usr/lib/libstdc++.so.5 #4 0xb7f86de2 in std::terminate () from /usr/lib/libstdc++.so.5 #5 0xb7f85e89 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.5 #6 0xb78f7f07 in Uuid::Uuid () from .../lib32/libourlibrary.so #7 0xb782409d in ...

स्मृति डीबगर या निष्पादन योग्य फ़ाइलों के डीबग संस्करण के साथ समस्या को पुन: उत्पन्न करने का प्रयास असफल रहे - समस्या गायब हो गई। हां, और प्रजनन स्वयं महंगा था - आमतौर पर समस्या के उठने से पहले 2-4 दिनों के लिए लोड के तहत प्रक्रिया का परीक्षण करना आवश्यक था - इससे अन्य घटकों के परीक्षण में देरी हुई जो लोड के तहत परीक्षणों के लिए समान बुनियादी ढांचे की आवश्यकता थी।

इसी तरह के कॉल स्टैक की खोज से वास्तव में कोई परिणाम नहीं मिला, और स्थिति का गतिरोध हो गया। किसी डिबगर का उपयोग किए बिना किसी स्मृति रिसाव का कारण ढूंढना आवश्यक था।

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

उत्सुकता से, यह पता चला कि फ़ाइल में "++ CCUNG0o" फॉर्म की 32,123,751 लाइनें शामिल हैं - केवल इन पंक्तियों में आकार में 3 जीबी की फ़ाइल में लगभग 275 एमबी व्याप्त है। जब एक फ़ाइल में इन पंक्तियों की खोज करते हैं, तो यह पता चला कि प्रत्येक ऐसे हस्ताक्षर ने 96-बाइट ब्लॉक (96b * 32,000,000 = 3Gb>) शुरू किया था!

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

0x248b818: 0x00 0x2b 0x2b 0x43 0x43 0x55 0x4e 0x47 <<==  «++CCUNG0o» 
      

        
        
        
      

     0x248b820: 0x30 0x6f 0xf8 0xb7 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b828: 0x6c 0xa8 0x78 0xb7 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b830: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b838: 0xa8 0x0e 0xd3 0xb7 0x3c 0xa2 0xfa 0xb7 
      

        
        
        
      

     0x248b840: 0xe8 0xae 0x82 0xb7 0x65 0x00 0x00 0x00 
      

        
        
        
      

     0x248b848: 0xc0 0x0e 0xd3 0xb7 0x38 0x9c 0xc8 0xb7 
      

        
        
        
      

     0x248b850: 0xf4 0x9b 0x04 0x08 0xe4 0x9c 0x04 0x08 
      

        
        
        
      

     0x248b858: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b860: 0x03 0x00 0x00 0x00 0xbe 0x80 0x79 0xb7 
      

        
        
        
      

     0x248b868: 0x58 0x80 0x79 0xb7 0x54 0xa9 0x78 0xb7 
      

        
        
        
      

     0x248b870: 0x98 0xb8 0x48 0x02 0x00 0x00 0x00 0x00 
      

        
        
        
      

     
      

        
        
        
      

     0x248b878: 0x00 0x2b 0x2b 0x43 0x43 0x55 0x4e 0x47 <<==  «++CCUNG0o» 
      

        
        
        
      

     0x248b880: 0x30 0x6f 0xf8 0xb7 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b888: 0x6c 0xa8 0x78 0xb7 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b890: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b898: 0xa8 0x0e 0xd3 0xb7 0x3c 0xa2 0xfa 0xb7 
      

        
        
        
      

     0x248b8a0: 0xff 0xff 0xff 0xff 0x65 0x00 0x00 0x00 
      

        
        
        
      

     0x248b8a8: 0xc0 0x0e 0xd3 0xb7 0x38 0x9c 0xc8 0xb7 
      

        
        
        
      

     0x248b8b0: 0xf4 0x9b 0x04 0x08 0xe4 0x9c 0x04 0x08 
      

        
        
        
      

     0x248b8b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
      

        
        
        
      

     0x248b8c0: 0x03 0x00 0x00 0x00 0xbe 0x80 0x79 0xb7 
      

        
        
        
      

     0x248b8c8: 0x58 0x80 0x79 0xb7 0x54 0xa9 0x78 0xb7 
      

        
        
        
      

     0x248b8d0: 0xf8 0xb8 0x48 0x02 0x00 0x00 0x00 0x00

पहली बार इंटरनेट पर इस तरह की एक पंक्ति की खोज से कोई उपयोगी परिणाम नहीं मिला, लेकिन फिर एक लिंक http://www.opensource.apple.com/ (दुर्भाग्य से अब और काम नहीं कर रहा) को निम्न स्निपेट के साथ मिला:

 // This is the exception class we report -- "GNUCC++\0". const _Unwind_Exception_Class __gxx_exception_class = ((((((((_Unwind_Exception_Class) 'G' << 8 | (_Unwind_Exception_Class) 'N') << 8 | (_Unwind_Exception_Class) 'U') << 8 | (_Unwind_Exception_Class) 'C') << 8 | (_Unwind_Exception_Class) 'C') << 8 | (_Unwind_Exception_Class) '+') << 8 | (_Unwind_Exception_Class) '+') << 8 | (_Unwind_Exception_Class) '\0');

फिर मैं अन्य थ्रेड्स के कॉल स्टैक पर लौट आया, और एक बहुत ही संदिग्ध धागा पाया जो स्पष्ट रूप से गिरावट के समय एक लूप में काम कर रहा था - और यह लूप भी अपवाद को संभालता है:

 (gdb) thread 20 [Switching to thread 20 (process 27635)]#0 0xb7e87921 in dl_iterate_phdr () from /lib/libc.so.6 (gdb) where #0 0xb7e87921 in dl_iterate_phdr () from /lib/libc.so.6 #1 0x0804e837 in _Unwind_Find_FDE (pc=0xb782409c, bases=0xb70209b4) at ../../gcc/unwind-dw2-fde-glibc.c:283 #2 0x0804c950 in uw_frame_state_for (context=0xb7020960, fs=0xb7020860) at ../../gcc/unwind-dw2.c:903 #3 0x0804cfbf in _Unwind_RaiseException_Phase2 (exc=0xbfde3f38, context=0xb7020960) at ../../gcc/unwind.inc:43 #4 0x0804d397 in _Unwind_Resume (exc=0xbfde3f38) at ../../gcc/unwind.inc:220 #5 0xb78f82b0 in Uuid::Uuid () from /home/'work/lib32/libourlibrary.so #6 0xb782409d in ...

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

काफी लीक नहीं है

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

कार्यक्रम सोलारिस के तहत काम किया, लोड के तहत, और मेमोरी का उपयोग 10-100 एमबी की वेतन वृद्धि में तेजी से बढ़ा, और शायद ही कभी - हर 2-3 दिनों में, और कभी-कभी दिन में 2-3 बार। जल्दी या बाद में, प्रक्रिया द्वारा उपयोग की जाने वाली मेमोरी 2+ जीबी तक बढ़ गई। इस स्थिति में, जब लोड शून्य तक कम हो जाता है, तब भी उपयोग की गई मेमोरी (RSS और VSS मान) कभी कम नहीं होती है।

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

स्थिति अजीब थी, लेकिन धीरे-धीरे, सिस्टम के विभिन्न घटकों को समाप्त करके और लॉग फ़ाइलों का सावधानीपूर्वक विश्लेषण करके, घटनाओं की तस्वीर को बहाल किया गया था।

सिस्टम को अपडेट करते समय, क्लाइंट प्रोग्रामों में से एक ने सिस्टम की निगरानी के लिए इच्छित संदेशों का हिस्सा भेजना बंद कर दिया। संयोग से, लापता संदेशों ने लेनदेन को बंद करने का संकेत दिया, और उन्हें आंतरिक बफ़र्स को साफ करना पड़ा। तदनुसार, भार में वृद्धि के साथ, बफ़र किए गए संदेश जमा होने लगे, जो जोड़े की प्रतीक्षा कर रहे थे। संयोग से, इस मामले में, संदेश atypically बड़े थे (सैकड़ों बाइट्स के बजाय दस किलोबाइट), और क्लाइंट प्रक्रियाओं की संख्या अपेक्षाकृत बड़ी थी (सामान्य 2-5 के बजाय कई दसियों)। लेकिन वास्तव में, ये सभी पैरामीटर पूरी तरह से सिस्टम द्वारा समर्थित सीमाओं (सामान्य कामकाज के अधीन) में फिट होते हैं। और, हालांकि कार्यक्रम ने आंतरिक बफ़र्स के आकार को सीमित नहीं किया, लेकिन इसने "खो" लेनदेन को साफ करने के लिए एक तंत्र का समर्थन किया - 10 मिनट से अधिक पुराने सभी अपूर्ण संदेश स्वचालित रूप से हटा दिए गए थे। और बस इस काउंटर ने हमेशा एक त्रुटि के कारण 0 दिखाया - तंत्र लगभग अविश्वसनीय असाधारण स्थिति के लिए डिज़ाइन किया गया था, लगभग कभी शामिल नहीं हुआ, और पर्याप्त परीक्षण नहीं किया गया। सफाई स्वयं ठीक से काम करती थी, लेकिन बड़ी संख्या में ग्राहकों के कारण बड़े मेमोरी लोड और गैर-मानक संदेशों के बड़े आकार के कारण पर्याप्त रूप से कुशल नहीं थी। आंकड़ों में दोषपूर्ण काउंटर के कारण समस्या का निदान बहुत मुश्किल था।

फिर, लोड कम होने पर मेमोरी वापस क्यों नहीं आई? बहुत सरल - सोलारिस में मानक प्रक्रिया मेमोरी मैनेजर केवल प्रक्रिया का पता स्थान बढ़ाता है, और पुन: उपयोग के लिए प्रक्रिया द्वारा मुक्त की गई मेमोरी को संग्रहीत करता है, इस प्रक्रिया को तीसरे पक्ष के पर्यवेक्षक के दृष्टिकोण से पृष्ठों को "व्यस्त" छोड़ देता है।

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

समस्या ग्राहकों को ठीक करने और बफर ओवरफ्लो से बचाने के पहले भी समाधान सरल था - "पुराने" लेन-देन की उम्र अस्थायी रूप से 30 सेकंड तक सीमित थी, और यह दिए गए लोड पर बफ़र्स की समय पर सफाई के लिए काफी था, बड़े अंतर के साथ। लेकिन निदान और समस्या निवारण में काफी समय लगा, मुख्यतः लॉग में गलत आँकड़ों के कारण।

एक उपसंहार के बजाय

व्यवहार में कौन दिलचस्प मामले थे - लिखो!

सी / सी ++ कार्यक्रमों में मेमोरी लीक - कई बगों का इतिहास

कोड लॉस मेमोरी

मैं मैं नहीं हूं, और मेरी स्मृति मेरी नहीं है

काफी लीक नहीं है

एक उपसंहार के बजाय

More articles: