2011-06-13 21 views
8

मेरे पास एक साधारण प्रोग्राम है जो धागा बनाता है, और यह थ्रेड समाप्त होने पर प्रतीक्षा करता है, और फिर प्रोग्राम भी समाप्त होता है। जब मैं इस प्रोग्राम को सी (जीसीसी) कंपाइलर के साथ संकलित करता हूं, और इसे वाल्ग्रिंड के साथ जांचता हूं, तो कोई समस्या नहीं होती है, लेकिन जब मैं इसे C++ (g ++) कंपाइलर से संकलित करता हूं, और वाल्ग्रिंड के साथ जांच करता हूं, तो यह दिखाता है कि मेरे प्रोग्राम में मेमोरी लीक है। क्या समस्या हो सकती है?मेमोरी लीक समस्या

यहाँ, मेरे कार्यक्रम,

#include <pthread.h> 
#include <errno.h> 
#include <stdlib.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <string.h> 


unsigned char b = 0; 


void* threadfunc1(void *pVoid) 
{ 
    while(b == 0) 
    { 
    usleep(10000); 
    } 
    pthread_exit(0); 
} 



int main(void) 
{ 

    int status; 
    pthread_attr_t tattr; 
    pthread_t thread1; 

    status = pthread_attr_init(&tattr); 
    status = pthread_attr_setdetachstate(&tattr,PTHREAD_CREATE_JOINABLE); 
    status = pthread_attr_setscope(&tattr,PTHREAD_SCOPE_SYSTEM); 

    if(pthread_create(&thread1, &tattr, threadfunc1, NULL) != 0) 
    { 
     exit(1); 
    } 

    usleep(1000000); 
    b = 1; 
    pthread_join(thread1, NULL); 
    usleep(2000000); 

    return 0; 
} 

इस परिणाम है जब मैं जी का उपयोग कर ++ यह संकलन, और valgrind में जाँच

==7658== HEAP SUMMARY: 
==7658==  in use at exit: 28 bytes in 1 blocks 
==7658== total heap usage: 2 allocs, 1 frees, 172 bytes allocated 
==7658== 
==7658== 28 bytes in 1 blocks are still reachable in loss record 1 of 1 
==7658== at 0x4024C1C: malloc (vg_replace_malloc.c:195) 
==7658== by 0x400C01E: _dl_map_object_deps (dl-deps.c:506) 
==7658== by 0x40117E0: dl_open_worker (dl-open.c:297) 
==7658== by 0x400D485: _dl_catch_error (dl-error.c:178) 
==7658== by 0x401119F: _dl_open (dl-open.c:586) 
==7658== by 0x428D0C1: do_dlopen (dl-libc.c:86) 
==7658== by 0x400D485: _dl_catch_error (dl-error.c:178) 
==7658== by 0x428D1C0: dlerror_run (dl-libc.c:47) 
==7658== by 0x428D2DA: __libc_dlopen_mode (dl-libc.c:160) 
==7658== by 0x4048876: pthread_cancel_init (unwind-forcedunwind.c:53) 
==7658== by 0x40489EC: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==7658== by 0x40464B7: __pthread_unwind (unwind.c:130) 
==7658== 
==7658== LEAK SUMMARY: 
==7658== definitely lost: 0 bytes in 0 blocks 
==7658== indirectly lost: 0 bytes in 0 blocks 
==7658==  possibly lost: 0 bytes in 0 blocks 
==7658== still reachable: 28 bytes in 1 blocks 
==7658==   suppressed: 0 bytes in 0 blocks 

तो, मैं गलत क्या कर रहा है, यह है मेरी त्रुटि या ..., जब मैं इसे जीसीसी के साथ संकलित करता हूं तो कोई समस्या नहीं होती है और जब मैं इसे संकलित करता हूं तो सी ++ मेमोरी लीक का उपयोग कर मौजूद होते हैं?

+0

बहु भाषा स्रोत फ़ाइलों लेखन कठिन है:

लेकिन मैं के लिए एक कॉल को देखने नहीं है। बहुत अधिक समस्याओं की अपेक्षा करें। मेरा सुझाव है कि आप केवल सी या सी ++ में से एक के साथ चिपके रहें। – pmg

+0

मुझे यह प्रोग्राम मेरे दोस्त से मिलता है, वह इसे मेकफ़ाइल के माध्यम से संकलित करता है, लेकिन मैंने इस प्रोग्राम के लिए नेटबीन में नई परियोजना बनाई है, क्योंकि मेरा डिफ़ॉल्ट कंपाइलर जीसीसी है, मुझे संकलन और चलाने के दौरान कोई समस्या नहीं थी, लेकिन जब मैं इसे मेकफ़ाइल के माध्यम से संकलित करता हूं , मेरे पास यह रिसाव है, इसलिए यह जानना दिलचस्प था क्यों? – akmal

उत्तर

6

आपका कार्यक्रम मेमोरी लीक की जरूरत नहीं है, आप करता नहीं मतलब स्मृति रिसाव

==7658== definitely lost: 0 bytes in 0 blocks 
==7658== indirectly lost: 0 bytes in 0 blocks 
==7658==  possibly lost: 0 bytes in 0 blocks 

"अभी भी पहुंचा जा सकता है"।

valgrind द्वारा "अभी भी पहुंचने योग्य" के बारे में यहां बहुत सारे प्रश्न हैं। उनमें से कुछ:

7

@Kiril कीरॉफ़ के जवाब के रूप में पहले ही बताया, अपने कार्यक्रम में कोई स्मृति लीक कर रहे हैं।

int pthread_attr_destroy(pthread_attr_t *attr); 
+0

pthread_attr_destroy के बारे में, ऐसा लगता है कि जब मैं इस प्रश्न को संपादित कर रहा था तो मैंने इसे हटा दिया;)। आपके उत्तर के लिए धन्यवाद! – akmal

+1

@akmal: यह बताता है कि कॉल गायब होने पर भी कोई रिसाव नहीं दिखाता है :) –

संबंधित मुद्दे