मेमोरी लीक

Question

खोजने के लिए एप्लिकेशन सत्यापनकर्ता का उपयोग कैसे करें मैं मानक उपयोगिताओं का उपयोग कर अपने आवेदन में मेमोरी लीक ढूंढना चाहता हूं। पहले मैंने अपनी खुद की मेमोरी आवंटक का उपयोग किया था, लेकिन अन्य लोगों (हाँ, आप एलियनफ्लिड) ने माइक्रोसॉफ्ट के एप्लिकेशन सत्यापनकर्ता का उपयोग करने का सुझाव दिया, लेकिन मुझे लगता है कि मैं इसे अपने रिसाव की रिपोर्ट नहीं कर सकता।

#include <iostream> 
#include <conio.h> 

class X 
    { 
    public: 
     X::X() : m_value(123) {} 
    private: 
     int m_value; 
    }; 

void main() 
{ 
X *p1 = 0; 
X *p2 = 0; 
X *p3 = 0; 

p1 = new X(); 
p2 = new X(); 
p3 = new X(); 
delete p1; 
delete p3; 
} 

यह परीक्षण स्पष्ट रूप से एक स्मृति रिसाव होता है: p2 new'd है लेकिन उसे हटाया नहीं मैं निम्नलिखित सरल आवेदन किया है।

मैं निम्नलिखित कमांड लाइन का उपयोग कर निष्पादन का निर्माण:

cl /c /EHsc /Zi /Od /MDd test.cpp 
link /debug test.obj 

मैं आवेदन सत्यापनकर्ता डाउनलोड किया गया (4.0.0665) और सभी चेक सक्षम होना चाहिए।

यदि अब मैं अपना टेस्ट एप्लिकेशन चलाता हूं तो मैं एप्लिकेशन सत्यापनकर्ता में इसका एक लॉग देख सकता हूं, लेकिन मुझे मेमोरी रिसाव दिखाई नहीं दे रहा है।

सवाल:

• क्यों नहीं आवेदन सत्यापनकर्ता एक रिसाव रिपोर्ट करता है?
• या आवेदन सत्यापनकर्ता वास्तव में लीक खोजने का इरादा नहीं है?
• यदि यह नहीं है कि आवेदन के अंत में स्पष्ट रूप से लीक की रिपोर्ट करने के लिए कौन से अन्य उपकरण उपलब्ध हैं (यानी नियमित स्नैपशॉट नहीं लेना और उन्हें तुलना करना क्योंकि यह 1 जीबी या उससे अधिक के आवेदन में संभव नहीं है), कॉल सहित आवंटन के स्थान के ढेर (ऐसा नहीं सीआरटी के अंत में सरल रिसाव रिपोर्टिंग)

मैं एक सभ्य उपयोगिता नहीं मिल रहा है, तो मैं अभी भी अपने स्वयं के स्मृति प्रबंधक का सहारा लेना पड़ (जो यह करता है पूरी तरह से)।

 
// debug_new.h 
#pragma once 

#include "crtdbg.h" 

#ifdef _DEBUG 
#ifndef DEBUG_NEW 
#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__) 
#endif 
#endif 

सभी सीपीपी फ़ाइलें:

 
#include "debug_new.h" 

... 

// After all other include lines: 
#ifdef _DEBUG 
#define new DEBUG_NEW 
#endif 

... 

लिखें कार्यक्रम प्रवर्तन कोड में इस बार:

_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF); 

में

Answer 1

सीआरटी स्मृति का पता लगाने (स्टैक ट्रेस के बिना) लीक एमएफसी, यह सब एमएफसी हेडर में पहले ही लागू हो चुका है। आप केवल सुनिश्चित करने की आवश्यकता है कि हर cpp फ़ाइल इन पंक्तियों में शामिल हैं:

 
#ifdef _DEBUG 
#define new DEBUG_NEW 
#endif 

प्रतिबंध: यह केवल 'नई' मेमोरी लीक, सभी लीक, एक और कार्यों की वजह से, malloc की तरह, पकड़ा नहीं कर रहे हैं फैल जाती है।

.h फ़ाइलों के अंदर कोई आवंटन न करें - उन्हें स्रोत लाइनों के बिना मुद्रित किया जाएगा, क्योंकि DEBUG_NEW को सभी # अंतर्निहित रेखाओं के बाद परिभाषित किया गया है।

Answer 2

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

X *p1 = 0; 
p1 = new X(); 

होना चाहिए:

shared_ptr <X> p1 = new X(); 

और तुम अब p1 लीक के बारे में चिंता। अभी भी बेहतर है, सब पर गतिशील आवंटन का उपयोग नहीं करते:

X x1; 

बफर अतिप्रवाह के लिए, हमेशा std :: स्ट्रिंग की तरह प्रकार जो इनपुट पर बढ़ेगा उपयोग करें, या वे विकसित नहीं यदि संभव हो तो अतिप्रवाह की पहचान करेगा और चेतावनी दी है आप।

मैं मेमोरी लीक से बचने में मेरी कौशल के बारे में दावा कर रहा हूँ नहीं - इस सामग्री वास्तव में काम करता है, और आप अपने कोड की व्यापार तर्क डिबगिंग के और अधिक कठिन कार्य के साथ पर प्राप्त करने के लिए अनुमति देता है।

Answer 3

मुझे एहसास है कि एप्लिकेशन सत्यापनकर्ता विशेष मामलों से बाहर निकलने का मार्ग है और इन्हें लीक के रूप में ध्वजांकित नहीं करता है - आखिरकार, पूरी प्रक्रिया ढेर प्रक्रिया से बाहर निकलने पर मुक्त होती है।

एक और नमूना लिखने का प्रयास करें जहां आप एक ही सूचक को फिर से शुरू करते हैं - मूल रूप से पिछले आवंटन के संदर्भ को खो देते हैं। यह निश्चित रूप से ध्वजांकित किया जाना चाहिए। मुझको परिणाम बता देना।

इसके अलावा, AppVerifier चिह्नित आरओ आदि

Answer 4

आवेदन सत्यापनकर्ता केवल DLLs में लीक पकड़ता भी बफर अतिप्रवाह, underflows पकड़ने चाहिए स्थानों ढेर करने के लिए लिख (आप सभी विकल्प सक्षम है)। रिसाव चेकबॉक्स में टूलटिप पढ़ने की कोशिश करें। यही वह कहता है।

Answer 5

Visual Leak Detector (v2.2) सीआरटी डीबग लाइब्रेरी से अधिक उपयोगी है क्योंकि यह दिखाएगा कि स्मृति आवंटन के लिए उपयोग किए गए पूर्ण कॉलस्टैक से रिसाव हो गया है।

Answer 6

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