हर C प्रोग्राम को मेमोरी-लीक-प्रूफ बनाइए
एक व्यंग्यात्मक ब्लॉग पोस्ट C memory leaks को “ठीक” करने का सुझाव देती है: `malloc` को intercept करके हर allocation को एक global list में रखो, ताकि leak detectors को सब कुछ अभी भी reachable लगे—भले ही इससे असल में leaks हों और memory corrupt हो। टिप्पणीकार बताते हैं कि यह unsafe और भ्रामक क्यों है, इसे Valgrind और LeakSanitizer जैसे real tools से तुलना करते हैं, और इस बहाने यह चर्चा करते हैं कि memory न free करना कब स्वीकार्य है (short-lived processes, arenas, FaaS) और कब robust memory management, RAII, या garbage collection ज़रूरी हैं।
प्रस्ताव की गंभीरता
- कई टिप्पणीकार इस पोस्ट को साफ़ तौर पर व्यंग्यात्मक मानते हैं, जिसका मक़सद यह दिखाना है कि leak detectors को कितनी आसानी से धोखा दिया जा सकता है; इसे production technique के रूप में नहीं देखा जा रहा।
- दूसरे लोग नोट करते हैं कि कोड इतना plausible दिखता है कि कम-अनुभवी C programmers इसे असली समाधान समझ सकते हैं, और यही चिंता का विषय है।
“bigbucket” malloc wrapper पर तकनीकी आलोचना
- यह wrapper सिर्फ allocations को एक global list में track करता है; user code जब
freeभी calls करता है, तब भी entries हटाई नहीं जातीं। - इससे असली leaks पैदा होते हैं: tracking list के लिए उपयोग हुई heap memory असीमित रूप से बढ़ती रहती है, और frees के बाद stored pointers dangling हो जाते हैं।
- यह उन programs में भी memory खत्म कर सकता है जो loop में हर चीज़ सही ढंग से free करते हैं।
- यह thread-safe नहीं है और हर allocation पर
dlsymcall करके भारी overhead पैदा करता है। - कुछ लोगों ने कहा कि आप मज़ाक को “पूरा” करने के लिए
freeको no-op redefine कर सकते हैं, ताकि dangling pointers पूरी तरह से टल जाएँ।
Leaks बनाम unbounded memory growth की परिभाषा
- कई लोग बताते हैं कि “reachable” memory भी व्यवहार में leak हो सकती है; GC वाली भाषाएँ भी forgotten references की वजह से leak कर सकती हैं।
- दूसरे इस बात पर ज़ोर देते हैं कि असल में मायने unbounded memory consumption का है, न कि यह कि memory तकनीकी रूप से reachable है या नहीं।
वास्तविक systems में जानबूझकर न-freeing
- कई उदाहरण दिए गए जहाँ free न करना जानबूझकर और स्वीकार्य है: short-lived programs, CGI/PHP-style per-request processes, arena/per-request allocators, HFT systems, कुछ game/audio engines, missiles या विशेष embedded systems, और वे servers जो समय-समय पर restart होते हैं।
- कुछ लोग तर्क देते हैं कि program exit पर freeing अक्सर बेकार होती है और performance को भी नुकसान पहुँचा सकती है (जैसे बड़े heaps को teardown करते समय page faults)।
Leak detection tools और व्यावहारिक रणनीतियाँ
- टिप्पणीकार Valgrind और LeakSanitizer जैसे असली tools सुझाते हैं, साथ ही arenas, per-module leak-free design, और उन “hot paths” का selective freeing जो allocations का बड़ा हिस्सा बनाते हैं।
- एक trick का ज़िक्र है: full cleanup logic सिर्फ़ leak checker के तहत ही चलाओ (जैसे runtime पर Valgrind detect करना)।
मेटा और measurement से जुड़ी समस्याएँ
- चर्चा में बार-बार यह विचार आता है कि अगर आप सिर्फ़ “tool X के तहत no leaks” के लिए optimize करेंगे, तो लोग उस metric के साथ खेलेंगे (Goodhart's law)।
- कई लोग नोट करते हैं कि बड़े codebases में असली leaks, retained लेकिन unused data से होने वाली memory bloat की तुलना में कम होते हैं; इसे ढूँढना कठिन है और यह सभी languages को प्रभावित करता है।