बूस्ट थ्रेड लीकेज सी ++

Question

क्या कोई मुझे बता सकता है कि बूस्ट थ्रेड लाइब्रेरी लीक है या नहीं। ऐसा लगता है कि यह करता है: Google कहता है कि मुझे दोनों बूस्ट थ्रेड और पर्थ्रेड के साथ संकलित करना चाहिए जो मैं कर रहा हूं और संस्करण 1.40 में यह समस्या ठीक हो गई है लेकिन मुझे अभी भी रिसाव मिल गया है। ध्यान दें कि यह ठीक संकलित करेगा लेकिन लीक का पता लगाया जाएगा। http://antonym.org/2009/05/threading-with-boost---part-i-creating-threads.html फिर भी एक ही समस्या:

#include <boost/thread.hpp> 
#include <boost/date_time.hpp> 

void t1(){} 

int main(void){ 
boost::thread th1(t1); 
th1.join(); 
return 1; 
} 

वेलग्रिंड के साथ मैं निम्नलिखित उत्पादन

HEAP SUMMARY: 
==8209==  in use at exit: 8 bytes in 1 blocks 
==8209== total heap usage: 5 allocs, 4 frees, 388 bytes allocated 
==8209== 
==8209== 8 bytes in 1 blocks are still reachable in loss record 1 of 1 
==8209== at 0x4024F20: malloc (vg_replace_malloc.c:236) 
==8209== by 0x4038CCB: boost::detail::get_once_per_thread_epoch() (in /usr/local/lib/libboost_thread.so.1.42.0) 
==8209== by 0x40329D4: ??? (in /usr/local/lib/libboost_thread.so.1.42.0) 
==8209== by 0x4032B26: boost::detail::get_current_thread_data() (in /usr/local/lib/libboost_thread.so.1.42.0) 
==8209== by 0x4033F32: boost::thread::join() (in /usr/local/lib/libboost_thread.so.1.42.0) 
==8209== by 0x804E7C3: main (testboost.cpp) 
==8209== 
==8209== LEAK SUMMARY: 
==8209== definitely lost: 0 bytes in 0 blocks 
==8209== indirectly lost: 0 bytes in 0 blocks 
==8209==  possibly lost: 0 bytes in 0 blocks 
==8209== still reachable: 8 bytes in 1 blocks 
==8209==   suppressed: 0 bytes in 0 blocks 

मैं भी निम्नलिखित वेबसाइट पर सूचीबद्ध कोड के साथ करने की कोशिश की हो।

Answer 1

यह 1_46_1 को बढ़ावा देने के संबंध में है, इसलिए यह आपके द्वारा उपयोग किए जा रहे संस्करण के लिए सच नहीं हो सकता है। यदि आप वास्तव में खुद को मनाने के लिए चाहते हैं तो बढ़ावा स्रोत देखें। (जब मैं आपका उदाहरण कोड चलाता हूं तो ओएसएक्स पर रिसाव डिटेक्टर किसी भी रिसाव का पता नहीं लगाता है)।

यह वास्तविक रिसाव नहीं है (जब तक कि कोई भी पथ्रेड के साथ कोई बग न हो, बूस्ट का पुराना संस्करण जिसका उपयोग आप कर रहे हों, या आपके कंपाइलर)।

get_once_per_thread_epoch एक नया uintmax_t mallocs और धागे की स्थानीय भंडारण में नक्शे एक epoch_tss_key एक संबद्ध नाशक कि मैप किए गए डेटा को मुक्त कर देते है साथ। इसलिए मॉलोकर्ड मेमोरी को मुक्त करने की गारंटी है।

मुझे वास्तव में समझ में नहीं आता कि क्यों वालग्रिंड इसे रिसाव के रूप में पहचान रहा है, लेकिन ऐसा इसलिए हो सकता है क्योंकि पर्थ्रेड निकास फ़ंक्शन वाल्ग्रिंड के बाद किसी बिंदु पर निष्पादित होते हैं। दूसरी संभावना यह है कि पाथ्रेड कार्य खुद को लीक कर रहे हैं, लेकिन मुझे दस्तावेज़ीकरण में कुछ भी नहीं देखा जो सुझाव देगा कि यह मामला है।