का उपयोग करते समय स्मृति 'संभावित रूप से खो गया' स्मृति की रिपोर्ट करता है मैं कई ग्लिब डेटास्ट्रक्चर (GHashTable, GSList इत्यादि) का उपयोग करके लाइब्रेरी विकसित कर रहा हूं। मैं वाल्ग्रिंड का उपयोग कर मेमोरी लीक के लिए अक्सर अपना कोड जांच रहा हूं। अधिकांश मुद्दों के मूल्यों को ठीक करने के लिए काफी आसान हैं, हालांकि कुछ ऐसे हैं जिन्हें मैं समझ नहीं सकता।ग्लिब डेटा प्रकार
इनमें से सभी को 'संभवतः खोया' बताया गया है। इस तरह के g_key_file_new के रूप में()
==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25
==29997== at 0x4004B11: memalign (vg_replace_malloc.c:532)
==29997== by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660)
==29997== by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3)
==29997== by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)
इसके अलावा कॉल स्टैक में नीचे
, वहाँ हमेशा एक चिकना फ़ंक्शन की कॉल है,:
valgrind स्टैकट्रेस के शीर्ष पर, मैं हमेशा एक ही 4 पुस्तकालयों को खोजने g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents()।
मेरे प्रश्न हैं:
किसी को भी इस पार आ गया है और इसके चारों ओर एक रास्ता मिल गया?
या यह कुछ है जो मैं उपेक्षा कर सकता हूं? क्या यह स्मृति संदेश का उपयोग कर ग्लिब के कारण है, जैसा कि here सुझाया गया है?
मैं उपयोग कर रहा हूँ
- valgrind-3.5.0
- चिकना-2.12.3
- जीसीसी (जीसीसी) 4.1.2 20,080,704 (रेड हैट 4.1.2-48)
- सेंटोस रिलीज 5.5 (अंतिम)
के साथ प्रोग्राम चला रहा है G_SLICE = always-malloc के साथ प्रोग्राम चलाना कोई खोया स्मृति नहीं दिखाता है, जो मेरे संदेह की पुष्टि करता है कि मेमोरी पूल की वजह से सभी (संभव) स्मृति हानि होती है। स्पष्ट उत्तर के लिए धन्यवाद Havoc पी। – ttreitlinger
हैवोक आप पुष्टि कर सकते हैं कि वैश्विक चर के बारे में आपका बयान अभी भी जीएलआईबी 2.32 के लिए सच है? धन्यवाद! –
हां, उदाहरण के लिए gconvert.c "स्थैतिक GHashTable * iconv_cache" आदि (केवल एक उदाहरण) –