mysql C++ क्लाइंट

Question

में मेमोरी लीक खोजने के लिए वालग्रिंड का उपयोग करना मैं मेमोरी लीक को आज़माने और ट्रैक करने के लिए वालग्रिंड का उपयोग कर रहा हूं mysql C++ क्लाइंट mysql से वितरित किया गया है।

दोनों उदाहरणों (resultset.cpp) और मेरे अपने कार्यक्रम में, एक 56 बाइट ब्लॉक है जो मुक्त नहीं है। अपने स्वयं के कार्यक्रम में, मैंने रिसाव को mysql क्लाइंट को कॉल करने का पता लगाया है।

1. मैं कैसे --show-पहुंच योग्य ब्लॉक की व्याख्या करना चाहिए:

   valgrind --leak-check=full --show-reachable=yes ./my-executable 
   
   ==29858== Memcheck, a memory error detector 
   ==29858== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. 
   ==29858== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info 
   ==29858== Command: ./my-executable 
   ==29858== 
   ==29858== 
   ==29858== HEAP SUMMARY: 
   ==29858==  in use at exit: 56 bytes in 1 blocks 
   ==29858== total heap usage: 693 allocs, 692 frees, 308,667 bytes allocated 
   ==29858== 
   ==29858== 56 bytes in 1 blocks are still reachable in loss record 1 of 1 
   ==29858== at 0x4C284A8: malloc (vg_replace_malloc.c:236) 
   ==29858== by 0x400D334: _dl_map_object_deps (dl-deps.c:506) 
   ==29858== by 0x4013652: dl_open_worker (dl-open.c:291) 
   ==29858== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
   ==29858== by 0x4012FF9: _dl_open (dl-open.c:583) 
   ==29858== by 0x7077BCF: do_dlopen (dl-libc.c:86) 
   ==29858== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
   ==29858== by 0x7077D26: __libc_dlopen_mode (dl-libc.c:47) 
   ==29858== by 0x72E5FEB: pthread_cancel_init (unwind-forcedunwind.c:53) 
   ==29858== by 0x72E614B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
   ==29858== by 0x72E408F: __pthread_unwind (unwind.c:130) 
   ==29858== by 0x72DDEB4: pthread_exit (pthreadP.h:265) 
   ==29858== 
   ==29858== LEAK SUMMARY: 
   ==29858== definitely lost: 0 bytes in 0 blocks 
   ==29858== indirectly lost: 0 bytes in 0 blocks 
   ==29858==  possibly lost: 0 bytes in 0 blocks 
   ==29858== still reachable: 56 bytes in 1 blocks 
   ==29858==   suppressed: 0 bytes in 0 blocks 
   ==29858== 
   ==29858== For counts of detected and suppressed errors, rerun with: -v 
   ==29858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6) 
   

   मैं इस बारे में कुछ प्रश्न हैं:

   यहाँ परिणाम जब मैं परीक्षण चलाने कर रहे हैं?

2. क्या यह ब्लॉक मेरे लिए त्रुटि और कोशिश में शून्य करने के लिए उपयोगी है?
3. यदि ब्लॉक उपयोगी नहीं है, तो क्या वाल्ग्रिंड में एक और तंत्र है जो मुझे रिसाव का पता लगाने में मदद करेगा?
4. यदि नहीं, तो क्या यह कुछ अन्य उपकरण है (उम्मीद है कि लिनक्स पर ओएसएस) मुझे इसे कम करने में मदद करने के लिए?

अग्रिम धन्यवाद ..

अद्यतन: यहाँ कोड है कि मैं pthread_exit की परिभाषा के लिए अपने सिस्टम पर पाया जाता है। मुझे यकीन नहीं है कि यह वास्तविक स्रोत है जिसे बुलाया जा रहा है। हालांकि, अगर यह है, तो क्या कोई यह समझा सकता है कि क्या गलत हो रहा है?

void 
pthread_exit (void *retval) 
{ 
    /* specific to PTHREAD_TO_WINTHREAD */ 

    ExitThread ((DWORD) ((size_t) retval)); /* thread becomes signalled so its death can be waited upon */ 
    /*NOTREACHED*/ 
    assert (0); return; /* void fnc; can't return an error code */ 
} 

Answer 1

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

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

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

संपादित

यह वास्तव में pthread_exit() कुछ बाहर निकलने पर सफाई नहीं कर रहा है, लेकिन के रूप में समझाया यह शायद की जरूरत नहीं है (या बहुत संभव है नहीं कर सकते हैं) एक बार यह उस बिंदु तक पहुँचता है।