2011-12-18 13 views
5

देखो कुछ पर मेरे मैक अजीब:बस एक पाश, और 33 लीक

==725== Memcheck, a memory error detector 
==725== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==725== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info 
==725== Command: ./a.out hello my friends 
==725== 
--725-- ./a.out: 
--725-- dSYM directory is missing; consider using --dsymutil=yes 
./a.out 
hello 
my 
friends 
==725== 
==725== HEAP SUMMARY: 
==725==  in use at exit: 6,146 bytes in 33 blocks 
==725== total heap usage: 33 allocs, 0 frees, 6,146 bytes allocated 
==725== 
==725== LEAK SUMMARY: 
==725== definitely lost: 0 bytes in 0 blocks 
==725== indirectly lost: 0 bytes in 0 blocks 
==725==  possibly lost: 0 bytes in 0 blocks 
==725== still reachable: 6,146 bytes in 33 blocks 
==725==   suppressed: 0 bytes in 0 blocks 
==725== Rerun with --leak-check=full to see details of leaked memory 
==725== 
==725== For counts of detected and suppressed errors, rerun with: -v 
==725== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) 

कोई जानता है क्यों, और कर सकता है, तो:

$> cat main.c 
#include <stdio.h> 
int main(int ac, char **av) { 
    for (int i = 0; i < ac; i++) 
     printf("%s\n", av[i]); 
    return 0; 
} 
$> gcc main.c -std=c99 
$> valgrind ./a.out hello my friends 

और यहाँ नतीजा है मुझे बताएं कि कहां से लीक आती है, मैं आभारी रहूंगा !!

एक अच्छा दिन है :-)

+0

'--leak-check = full' के साथ पुन: चलाएं। आप शायद देखेंगे कि आवंटन आपके पर्यावरण द्वारा किए गए सिस्टम सामान (एक-ऑफ स्टार्टअप/प्रारंभिक चीजें) हैं जो वास्तव में लीक नहीं हैं। – Mat

+1

क्या आपने "लीक मेमोरी के विवरण देखने के लिए - स्लेक-चेक = पूर्ण के साथ फिर से शुरू किया" जैसा कि वाल्ग्रिंड आउटपुट संदेश द्वारा सुझाया गया है? – bobbymcr

उत्तर

9

ये लीक नहीं हैं। still reachable के रूप में सूचीबद्ध ऑब्जेक्ट्स आपको परेशान नहीं करना चाहिए। यदि आपके ऊपर उपरोक्त पंक्तियों में शून्य-शून्य मान होगा तो इसे अलार्म घंटी बजानी चाहिए!

still reachable के रूप में सूचीबद्ध 33 ब्लॉक शायद आपके मानक पुस्तकालय द्वारा printf कॉल के अंदर आवंटित कुछ ब्लॉक हैं। इसके बारे में चिंतित होने के लिए कुछ नहीं।

एक ही प्रश्न के लिए this answer पर एक नज़र डालने पर विचार करें।

+0

बिल्कुल सही। उत्तर के लिए धन्यवाद :-) – DCMaxxx

3

"still reachable" जब कोई प्रोग्राम समाप्त हो गया है तो वास्तव में चिंता करने के लिए कुछ भी नहीं है।

"still reachable" का मतलब है कि आवंटित स्मृति आवंटित नहीं की गई है, लेकिन अभी भी इस स्मृति की ओर इशारा करते हुए पॉइंटर्स हैं। इसके लिए valgrind इसे एक वास्तविक स्मृति "रिसाव" के रूप में चिह्नित नहीं करता है।

अक्सर समय बिताने के लिए समय बर्बाद होता है: एप्लिकेशन समाप्त होने से पहले आवंटित स्मृति में आवंटित किया जाता है, आवंटित स्मृति किसी भी तरह से ओएस को वापस कर दी जाएगी क्योंकि आवेदन समाप्त हो रहा है।

+0

मेरे अनुभव में, आपके चलाने के अंत में सभी वस्तुओं को सही ढंग से मुक्त करने का प्रयास करना महत्वपूर्ण है। मुझे इस तरह की बहुत सारी बग मिली है। यह सच है कि माना जाता है कि 'रिसाव' की गुरुत्वाकर्षण न्यूनतम है, लेकिन शुद्धता में उपयोग करने वाले व्यायाम में व्यापक प्रतिक्रियाएं होती हैं। बड़ी परियोजनाओं पर यह एक वास्तविक अंतर बना सकता है। यह वास्तव में 2 बड़ी परियोजनाओं (सी के 500 के और 150 के लाइनों) पर किया था जिस पर मैंने काम किया था। –