Https://github.com/ElektraInitiative/libelektra/issues/3140 से संबंधित है

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

क्या आप सुनिश्चित हैं कि बाइंडिंग कहीं लीक नहीं हैं?

हां, मुझे यकीन है - रनटाइम के दौरान किसी एप्लिकेशन के मेमोरी उपयोग का निरीक्षण करना संभव है, इन आंकड़ों में C कोड द्वारा आवंटन शामिल नहीं हैं और वे एप्लिकेशन / टेस्ट के कुल मेमोरी उपयोग के पास नहीं हैं, जिसका अर्थ होगा कि मेमोरी का बड़ा हिस्सा सी में आवंटित किया गया है।

मेरा संदेह यह है कि कुंजियों को मुक्त नहीं किया जाता है क्योंकि रेफरी काउंटर != 0 , हालांकि यह 0 होना चाहिए।

इसका मतलब यह है कि बाइंडिंग सी एपीआई को इस तरह से कॉल करता है जो इस मेमेल को ट्रिगर करता है। दुर्भाग्य से मुझे नहीं पता, इसलिए मुझे नहीं पता कि ऐसा क्यों होता है।

क्या आप शायद एक छोटा सी उदाहरण निकाल सकते हैं जो रिसाव को ट्रिगर करता है? मैं benchmarks/kdb.c में बहुत कुछ करता हूं और वहां कोई रिसाव नहीं है, इसलिए यह ठीक उसी तरह से करने की जरूरत है जो आपके बेंचमार्क लीक को ट्रिगर करने के लिए करता है।

मुद्दे की रिपोर्टिंग के लिए धन्यवाद!

मैं यहाँ पूरी तरह से @mpranj से सहमत हूँ, हमें समस्या को कम से कम करने की आवश्यकता है, जिसमें कई भाषाएं शामिल हैं, कुछ भी खोजना मुश्किल है।

क्या आप शायद एक सी प्रोग्राम लिख सकते हैं जो कॉल बाइंडिंग से जारी किए गए कॉल अनुक्रम को पुन: पेश करता है? एक बार हमारे पास ऐसा हो जाए, हम सी प्रोग्राम को टेस्ट केस के लिए कम कर सकते हैं।

Btw। ऊपर दिए गए कमांड को चलाने की कोशिश मैं काफी पहले विफल हो गया: # 3159

मैं कल तक सी में इसे पुन: पेश करने की कोशिश करूंगा

मैं सफलतापूर्वक इस मुद्दे reproduced यहाँ । benchmarks/memoryleak.c बेंचमार्क चलाएं और कीसेट्स प्राप्त करते समय मेमोरी को देखें - और खाली होने पर नीचे न जाएं।

DB में कुंजियों की ध्यान देने योग्य राशि जोड़ने के लिए मत भूलना .. मैंने इसे 100k कुंजी के साथ परीक्षण किया।

उदाहरण बनाने के लिए धन्यवाद! मैं एक नजर मार लूगां।

पहली नज़र में, वास्तव में एक प्रत्यक्ष रिसाव है, आपको पैरेंट को मुक्त करने की आवश्यकता है:
https://github.com/raphi011/libelektra/blob/afcbcf5c8138be8de6ba9b1a9e559bc673ff887f/benchmarks/mororyleak.c#L22

यह छोटा रिसाव शायद आपके अवलोकनों का कारण नहीं है।

एक तरफ ध्यान दें के रूप में: mmap कैश का उपयोग कर, मैं कैश के बिना से भी कम स्मृति की खपत पर ध्यान दें। शायद मुझे इसे अपनी थीसिस में जोड़ने की आवश्यकता है: मुस्कान:। (कैश: ~ २०० एम बनाम नो कैश: ~ ६०० एम)

ऐसा लगता है कि हम dlopen() / dlclose() माध्यम से "लीक" कर रहे हैं। kdb का उपयोग करके निम्नलिखित देखा जा सकता है लेकिन kdb-static (केवल एक अंश) का उपयोग करके नहीं:

valgrind --leak-check=full --show-leak-kinds=all ./bin/kdb ls user
[...]
==48451== 1,192 bytes in 1 blocks are still reachable in loss record 6 of 6
==48451==    at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==48451==    by 0x400BB11: _dl_new_object (in /usr/lib64/ld-2.30.so)
==48451==    by 0x400642F: _dl_map_object_from_fd (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4009315: _dl_map_object (in /usr/lib64/ld-2.30.so)
==48451==    by 0x400DB24: openaux (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4DFE8C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48451==    by 0x400DF6A: _dl_map_object_deps (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4013AC3: dl_open_worker (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4DFE8C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48451==    by 0x401363D: _dl_open (in /usr/lib64/ld-2.30.so)
==48451==    by 0x496139B: dlopen_doit (in /usr/lib64/libdl-2.30.so)
==48451==    by 0x4DFE8C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
[...]

आपका उदाहरण कई हैंडल अधिक हैंडल खोलता है, इसलिए यह इस तरह दिखता है:

==48735== 72,704 bytes in 1 blocks are still reachable in loss record 8 of 8
==48735==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==48735==    by 0x4F860A9: ??? (in /usr/lib64/libstdc++.so.6.0.27)
==48735==    by 0x400FD59: call_init.part.0 (in /usr/lib64/ld-2.30.so)
==48735==    by 0x400FE60: _dl_init (in /usr/lib64/ld-2.30.so)
==48735==    by 0x4013DBD: dl_open_worker (in /usr/lib64/ld-2.30.so)
==48735==    by 0x4A088C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48735==    by 0x401363D: _dl_open (in /usr/lib64/ld-2.30.so)
==48735==    by 0x48C739B: dlopen_doit (in /usr/lib64/libdl-2.30.so)
==48735==    by 0x4A088C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48735==    by 0x4A08962: _dl_catch_error (in /usr/lib64/libc-2.30.so)
==48735==    by 0x48C7B08: _dlerror_run (in /usr/lib64/libdl-2.30.so)
==48735==    by 0x48C7429: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.30.so)

उदाहरण में आप बहुत सारे केडीबी हैंडल खोल रहे हैं, जो इस प्रभाव को महत्वपूर्ण मेमोरी खपत में जोड़ते हैं। यदि आप केवल एक हैंडल खोलते हैं, तो यह कम होना चाहिए। @ raphi011 मुझे नहीं पता कि क्या आप अपने बेंचमार्क के लिए kdb-static उपयोग कर सकते हैं। बेंचमार्क को elektra-static लाइब्रेरी से लिंक करते समय मैं उसी का अवलोकन नहीं कर सकता:

==54836== HEAP SUMMARY:
==54836==     in use at exit: 0 bytes in 0 blocks
==54836==   total heap usage: 6,456,631 allocs, 6,456,631 frees, 272,753,180 bytes allocated
==54836== 
==54836== All heap blocks were freed -- no leaks are possible
==54836== 
==54836== For lists of detected and suppressed errors, rerun with: -s
==54836== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

मुझे फिलहाल यकीन नहीं है कि हम dlopen() की समस्याओं के बारे में क्या कर सकते हैं।

यह नए elektrad सर्वर का सरलीकृत अनुकरण है। चूंकि हम एक ही समय में सिस्टम को कॉन्फ़िगर करने वाले कई उपयोगकर्ताओं का समर्थन करना चाहते हैं, इसलिए हमें कई हैंडल (संघर्ष हैंडलिंग आदि) का समर्थन करने की आवश्यकता है।

मुझे अभी भी लगता है कि यह समस्या की जड़ नहीं है। समस्या यह है कि Key / KeySets को मुक्त नहीं किया गया है। यदि आप मूल कुंजी को "system" जिसमें बहुत कम कुंजियाँ हैं, तो आप देखेंगे कि मेमोरी की खपत बहुत कम है।

@ markus2330 आपको क्या लगता है?

संपादित करें: यह भूल जाते हैं।

मुझे नहीं लगता कि हम वहां मेमोरी लीक कर रहे हैं।
https://gist.github.com/mpranj/bbdf00af308ed3f5b3f0f35bc832756f~~

मैं उसी चीज़ का निरीक्षण कर सकता हूं जो आप HTOP के साथ बता रहे हैं और ऊपर दिए गए जिस्ट से कोड का उपयोग करते हुए मेमोरी उपयोग करते हैं।

तो आप मुझे बता रहे हैं कि यह बिल्कुल सामान्य है कि एलेक्ट्रा की मेमोरी की खपत कभी कम नहीं होती है?

तो आप मुझे बता रहे हैं कि यह बिल्कुल सामान्य है कि एलेक्ट्रा की मेमोरी की खपत कभी कम नहीं होती है?

मैं ऐसा नहीं कह रहा हूं। मैं कह रहा हूं कि मैंने इलेक्ट्रा की परवाह किए बिना वही मनाया। मैंने अभी देखा कि मेरा अवलोकन केवल वैलग्राइंड के साथ चलने पर ही सत्य है, इसलिए हो सकता है कि अन्य कारणों से अंत तक वेलग्रिंड फ्री () आईएनजी न हो।

https://stackoverflow.com/questions/40917024/memory-leak-after-using-calloc-and-free

ऐसा लगता है क्योंकि आप सूचक को मुक्त करने से पहले बदल रहे हैं

ऐसा लगता है क्योंकि आप सूचक को मुक्त करने से पहले बदल रहे हैं

मैं ऐसा नहीं कर रहा हूं और वैलग्राइंड, जिस्ट में कोड के लिए कोई रिसाव नहीं दिखाता है। लेकिन उदाहरण भूल जाते हैं, यह अप्रासंगिक है क्योंकि यह केवल तभी मुफ्त नहीं होता है जब वेलग्रिंड के अंदर चलाया जाता है, अन्यथा मेमोरी मुफ्त है () डी बहुत तुरंत।

क्या अधिक प्रासंगिक है: मैंने देखा कि आप benchmark_createkeys का उपयोग करके क्या रिपोर्ट कर रहे हैं जो KDB का उपयोग नहीं करता है। वहाँ संसाधन भी मुफ्त नहीं हैं () तुरंत, लेकिन वैलेग्राइंड बिल्कुल 0 लीक दिखाता है। मैं चकरा गया।

@ markus2330 आपको क्या लगता है?

केवल KeySets के साथ निश्चित रूप से कोई रिसाव नहीं होना चाहिए। (KDB के साथ हम पूरी तरह से सब कुछ नियंत्रित नहीं कर सकते क्योंकि प्लगइन्स लीक होने वाले अन्य पुस्तकालयों को लोड कर सकते हैं।)

@ raphi011 क्या आप एक PR बना सकते हैं या मुझे समस्या का पुनरुत्पादन करने वाले न्यूनतम उदाहरण की ओर

https://github.com/raphi011/libelektra/tree/memoryleak यहां आप जाएं। मैंने अपने पिछले उदाहरण को प्रिंट करके यह बताया है कि कितने संदर्भों को ksDel द्वारा मुक्त नहीं किया गया था क्योंकि प्रमुख संदर्भ > 0 ।

यदि आप बिना मान्यता के बेंचमार्क चलाते हैं तो आप देख सकते हैं कि चाबियाँ मुक्त नहीं हुई हैं।

मैं इस रेपो का संकलन नहीं कर सकता, मुझे त्रुटि मिली:

CMake Error: Error processing file: /home/markus/Projekte/Elektra/repos/libelektra/scripts/cmake/ElektraManpage.cmake
make[2]: *** [src/bindings/intercept/env/CMakeFiles/man-kdb-elektrify-getenv.dir/build.make:61: ../doc/man/man1/kdb-elektrify-getenv.1] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:17236: src/bindings/intercept/env/CMakeFiles/man-kdb-elektrify-getenv.dir/all] Fehler 2

क्या आप मुख्य मास्टर को छूट दे सकते हैं?

और कृपया एक पीआर करें, यह परिवर्तनों को देखना बहुत आसान है, फिर।

यदि आप बिना मान्यता के बेंचमार्क चलाते हैं तो आप देख सकते हैं कि चाबियाँ मुक्त नहीं हुई हैं।

क्या आप एक रन के आउटपुट को यहां कॉपी कर सकते हैं?

मैंने देखा कि आप बेंचमार्क_क्रिएटेकी का उपयोग करके क्या रिपोर्ट कर रहे हैं जो केडीबी का उपयोग नहीं करता है। वहाँ संसाधन भी मुफ्त नहीं हैं () तुरंत, लेकिन वैलेग्राइंड बिल्कुल 0 लीक दिखाता है। मैं चकरा गया।

मुझे लगता है कि हमें पहले इस ट्रेस का पालन करना चाहिए, क्योंकि यह समझना बहुत आसान है कि क्या हमारे पास केवल कीसेट्स हैं।

हो सकता है कि हमने मान्य करने के लिए गलत दमन जोड़ा?

एक साइड नोट के रूप में: एमएमएपी कैश का उपयोग करते हुए, मैं कैश के बिना मेमोरी मेमोरी खपत को भी नोटिस करता हूं। शायद मुझे इसे अपनी थीसिस मुस्कान में जोड़ना होगा। (कैश: ~ २०० एम बनाम नो कैश: ~ ६०० एम)

ये निश्चित रूप से बहुत अच्छी खबर है।

यहां आप जाएं: https://github.com/ElektraInitiative/libelektra/pull/3172

हो सकता है कि हमने मान्य करने के लिए गलत दमन जोड़ा?

जब मैंने परीक्षण चलाए, तो वाल्ग्रिंड ने बिना किसी दमन के उपयोग की सूचना दी, लेकिन आपके माइलेज में मेरी भिन्नता थी।

मुझे लगता है कि मुझे अपने बेंचमार्क के दौरान समस्या मिली। मेरे लिए समस्या प्रत्येक कुंजी के लिए मेटा कीसेट का उत्सुक आवंटन है। मेरी शाखा पर एक गंदे परीक्षण के बाद, उत्सुक मेटा कीसेट को हटाकर मेमोरी खपत को जल्दी से ksDel () के बाद नीचे ले जाया जाता है। शायद यह # 3142 द्वारा तय किया गया है क्योंकि यह उस कोड को बदलता है जिसके बारे में मैं बात कर रहा हूं।

ठीक है, तो हमें देखते हैं कि # 3142 समस्या को ठीक करता है!

@ raphi011 ने # 3081 से पहले भी समस्या

3142 अब मर्ज हो गया है। @ raphi011 आप जाँच कर सकते हैं कि क्या समस्या अभी भी है?

दुर्भाग्य से हाँ

मेरे लिए यह करने के लिए कम से कम का समाधान / कुछ समस्या को कम लगता है। मैं अब ~ 2GB मेमोरी का उपयोग करके लाखों कुंजियों के साथ बेंचमार्क चला सकता हूं, जबकि यह उसी बेंचमार्क के लिए> 20GB मेमोरी का उपयोग करने से पहले क्रैश हो गया।

मेरे लिए यह करने के लिए कम से कम का समाधान / कुछ समस्या को कम लगता है। मैं अब ~ 2GB मेमोरी का उपयोग करके लाखों कुंजियों के साथ बेंचमार्क चला सकता हूं, जबकि यह उसी बेंचमार्क के लिए> 20GB मेमोरी का उपयोग करने से पहले क्रैश हो गया।

मैंने इसकी तुलना पिछले संस्करण से नहीं की है, लेकिन मुझे पूरा यकीन है कि यह पहले की तुलना में कम मेमोरी का उपयोग करता है। आज जांच करेंगे!

स्मृति अभी भी मुक्त नहीं हुई है।

आपको हर free (पढ़ें: ksDel ) के बाद malloc_trim(0) कॉल करने की आवश्यकता है। यह स्मृति को तुरंत ओएस पर वापस लाने के लिए चमकता है। यह "अजीब व्यवहार" को ठीक करना चाहिए जिसे आप लोग देख रहे हैं। ओह, और पढ़ने में मज़ा है और glibc में खुदाई :-)

मैंने आगे परीक्षण / फिक्सिंग के लिए # 3183 बनाया।

मुझे एक मेमलैक मिला (एक kdbGet रिटर्न कुंजियों में मुक्त नहीं किया गया था)।

लेकिन "ksClose ने 532 कुंजियों को मुक्त नहीं किया" की बढ़ती संख्या संभवतः पेरेंटे में केवल चेतावनी है। यदि आप NUM_RUNS को उच्च बनाते हैं, जैसे कि 100, यह कुछ बिंदु पर स्थिर हो जाता है, क्योंकि चेतावनियों की संख्या 100 तक सीमित है। मेरे लिए यह अधिकतम हो जाता है। "ksClose ने 901 कुंजी को मुक्त नहीं किया"। एक पेरेंटेकी प्रति हैंडल होने से यह समस्या ठीक हो जाएगी।

# 3183 द्वारा बंद किया गया