Go में Valgrind सपोर्ट जोड़ा गया

• Go भाषा ने आधिकारिक रूप से Valgrind सपोर्ट जोड़ा है
• इस बदलाव से memory error detection और debugging क्षमताएं मजबूत हुई हैं
• डेवलपर अब memory leak और access error को अधिक आसानी से पहचान सकते हैं
• Valgrind के साथ बेहतर compatibility के कारण porting और maintenance का काम अधिक efficient हो सकता है
• अलग-अलग platforms पर Go code की stability का आकलन करना आसान हो गया है

---

Go में Valgrind सपोर्ट जोड़े जाने का महत्व

• Go में Valgrind सपोर्ट जोड़े जाने से अब डेवलपर आधिकारिक रूप से memory error detection tool का उपयोग कर सकते हैं
• इस बदलाव से Go code में Use-after-free, memory leak, गलत memory access जैसी समस्याओं की जांच संभव हो गई है
• Valgrind कई भाषाओं में memory issue detection के लिए व्यापक रूप से इस्तेमाल होता है, और Go community के लिए यह reliability और durability को मजबूत करने वाला महत्वपूर्ण बदलाव है
• जोड़ी गई यह सुविधा कई platforms पर Go programs के लिए debugging, quality verification, stability assessment जैसे काम आसान बनाती है
• इस अपडेट का मुख्य महत्व यह है that Go runtime layer में Valgrind के लिए instrumentation code शामिल किया गया है

Valgrind क्या है?

• Valgrind एक open source development tool है जो memory error detection, thread error, memory leak आदि की जांच करता है
• यह C, C++ जैसी system programming languages में व्यापक रूप से उपयोग होता है और memory management issues की सटीक पहचान प्रदान करता है

इस फीचर जोड़ने का सारांश

• इस बदलाव से जुड़ा code instrumentation Go runtime में dynamically allocated memory से संबंधित events को Valgrind द्वारा सटीक रूप से track करने में सक्षम बनाता है
• डेवलपर अब Go programs को Valgrind के साथ चलाकर संभावित memory problems या गलत pointer access जैसी समस्याओं का प्रभावी ढंग से diagnosis कर सकते हैं
• नतीजतन, Go आधारित infrastructure या services में high-quality code बनाए रखना और issues को पहले से रोकना जैसी बढ़त मिलती है

बदलाव के अपेक्षित प्रभाव

• Go projects में memory error detection और code quality improvement की प्रक्रिया अब और अधिक सटीक होने की संभावना है
• अलग-अलग platforms पर deploy किए जाने वाले Go code की compatibility और reliability सुनिश्चित करना अधिक आसान होने की उम्मीद है

[taptaps]

जब भी Go भाषा पर पोस्ट देखते हैं, तो लगता है कि टिप्पणियों में हमेशा
'लेकिन Rust में ऐसा नहीं होता', 'Rust में इसकी ज़रूरत ही नहीं पड़ती' ज़रूर होता है, हाहा

[GN⁺]

Hacker News टिप्पणियाँ

• मैं उस CL का लेखक हूँ। इस सुधार के ज़रिए मैं memory initialization tracking फीचर का इस्तेमाल crypto code के निर्धारित समय के भीतर चलने की जांच करने के लिए करना चाहता हूँ (constant-time testing)। यह लगभग 15 साल पहले agl द्वारा प्रस्तावित और BoringSSL में किए गए तरीके जैसा है संबंधित लिंक, क्योंकि इस गुण को टेस्ट करना वास्तव में बहुत कठिन है। आगे भी Go में Valgrind उपयोग को सक्षम करते हुए यह देखना दिलचस्प होगा कि runtime की memory handling को ठीक से ट्रैक किया जा सकता है या नहीं। हालांकि यह ज़ोर देकर कहना चाहूँगा कि यह support अभी experimental चरण में है। मुझे 100% यक़ीन नहीं कि हर configuration में सब कुछ ठीक चलेगा, और कुछ कठिन-समझ आने वाली warnings और बढ़ सकती हैं।
  • क्या community ऐसी किसी दिशा में मदद कर सकती है जहाँ development आगे बढ़ सके?
  • यह वास्तव में बहुत शानदार फीचर लगता है। उम्मीद है इससे Go की दूसरी समस्याएँ भी सामने आएँगी। लेकिन क्या इतना जटिल tracking किए बिना सिर्फ़ crypto function को अलग-अलग inputs देकर execution time सीधे मापकर, और अगर सब लगभग बराबर हों तो constant-time होने की जांच नहीं की जा सकती? उदाहरण के लिए Garbage Collection या OS noise की स्थिति में भी कई inputs डालकर समय मापा जाए और अगर epsilon त्रुटि के भीतर हो तो शायद काफ़ी हो। कुछ CPU में conditional branch counter भी होते हैं, जिनका rr debugger उपयोग करता है। इस मान से decryption से पहले और बाद की branching count की तुलना करने का तरीका भी हो सकता है (agl के लेख में यह दावे से जुड़ा है कि branch समान हों तो constant time मिलता है)। और पहले 10 decryption के अधिकतम समय में थोड़ा margin जोड़कर उसके बाद हर decryption में time padding डालना भी संभव हो सकता है (noop चलाने जैसी चीज़ों से), ताकि समय को ज़बरदस्ती बराबर रखा जा सके। अगर upper bound से ज़्यादा समय लगे तो program crash करा देने वाला assert भी लगाया जा सकता है। लेकिन अगर OS scheduling के कारण timing बिगड़ जाए तो यह तरीका मुश्किल हो जाता है।
• Valgrind headers को tree में जोड़कर cgo से अलग-अलग Valgrind client request macros बुलाने के बजाय, एक assembly function से ज़रूरी निर्देश सीधे भेजकर client request trigger करने का तरीका चुना गया है, यह बहुत अच्छा लगा। bootstrap toolchain के लिए यही वांछनीय तरीका है: न्यूनतम building blocks बनाओ और बाकी सब भाषा स्तर पर संभालो।
  • अगर यह तरीका न चुना जाता और पुराना तरीका या कोई दूसरा विकल्प टाला जाता, तो Go की तरह process को सरल रखते हुए लगभग समान performance कैसे हासिल की जाती? मुझे लगता है यह आगे भी सोचे जाने वाला प्रश्न है।
• यह देखना अच्छा लगता है कि rsc अब भी सक्रिय रूप से योगदान दे रहे हैं, खासकर commit message में टिप्पणियाँ जोड़ना प्रभावशाली है। उम्र बढ़ने के साथ मुझे commit messages की अहमियत और ज़्यादा महसूस होने लगी है। सिर्फ़ "valgrind जोड़ा" जैसा लिख देने से बाद में archive करते समय कोई खास मदद नहीं मिलती।
  • rsc सचमुच rockstar स्तर के developer हैं। अब वे issue या PR management में AI का उपयोग जैसे नए प्रयोग भी कर रहे हैं, और उम्मीद है कि इससे काफ़ी अच्छे नतीजे मिलेंगे।
• यह फीचर तभी प्रभावी है जब सभी packages पर test लागू हो। नहीं तो असंबंधित warnings में असली चीज़ दब जाती है। इसी कारण Python code में Valgrind इस्तेमाल करना मुश्किल होता है।
  • अगर यह बात सही है तो वही बात C, C++ पर भी लागू होनी चाहिए। मेरे मामले में मैंने Python + Boost C++ hybrid program पर Valgrind इस्तेमाल किया था, और suppressions file पर एक घंटा काम करने के बाद उसे बिना समस्या के उपयोग कर पाया।
  • बहुत ज़्यादा जानकारी को व्यवस्थित करके सारांश बनाने में local LLM उपयोगी हो सकता है। इसी वजह से Valgrind जैसे batteries-included toolchain की भूमिका बहुत महत्वपूर्ण है।
  • Go environment में "सभी packages को test करना" से आपका क्या मतलब है?
• Valgrind एक छुपी हुई superpower है। मैं जो ज़्यादातर software लिखता हूँ, उसमें make check से test cases चलाता हूँ, और make check-valgrind से उन्हीं tests को Valgrind environment में एक बार और चलाता हूँ। दूसरा वाला सिर्फ़ developer PC पर उपयोग करता हूँ। इससे memory leak और सूक्ष्म bugs अक्सर पकड़ में आ जाते हैं।
  • कुछ हद तक सहमत हूँ, लेकिन जैसे ही बात multithreading (जहाँ Go बहुत उपयोग होता है) पर आती है, Valgrind की abstraction layer उतनी अच्छी तरह काम नहीं करती। यह मेरी उस आख़िरी गहरी पड़ताल के आधार पर कह रहा हूँ जो मैंने C++ code में की थी। चूँकि यह अपना scheduler इस्तेमाल करता है, इसलिए वास्तविक दुनिया की concurrency और race condition जैसी समस्याएँ Valgrind में उतनी साफ़ नहीं दिखतीं। और सामान्य रूप से performance penalty भी काफ़ी भारी होती है। फिर भी, कई बार इसने बहुत मदद की है और इसके बने रहने के लिए मैं आभारी हूँ।
• यह support सचमुच कूल है। इससे शायद कुछ और bugs उजागर होंगे। मेरी जिज्ञासा यह है कि Valgrind ही क्यों चुना गया? मुझे लगता है कि Clang AddressSanitizer(asan) और MemorySanitizer(msan) ज़्यादा तरह की errors (जैसे use-after-return) पकड़ते हैं, और वे काफ़ी तेज़ भी हैं।
  • Go clang/llvm का उपयोग नहीं करता, इसलिए ऐसे tools लागू नहीं किए जा सकते।
  • Go में पहले से अपना msan/asan support कई सालों से मौजूद है।
  • Valgrind काफ़ी ज़्यादा तेज़ है, और इसे चल रहे program से attach करके भी इस्तेमाल किया जा सकता है।
  • Valgrind में memory tracking, memory profiling जैसी कई सुविधाएँ भी हैं, इसलिए performance tracking के नज़रिए से भी यह बहुत बेहतरीन है।
• बहुत प्रभावशाली। Go की सबसे बड़ी समस्याओं में से एक profiling और बार-बार होने वाला memory leak / memory pressure है। अभी मुझे इस समस्या को हल करने के लिए कोई स्पष्ट alternative tool पता नहीं है।
  • इसके बारे में और विस्तार से सुनना चाहूँगा। आपको profiling में ठीक-ठीक कौन सी समस्या आ रही है? अगर inuse memory profile memory leak ट्रैक करने के लिए काफ़ी नहीं है (क्या आपने gorefs इस्तेमाल किया है?), तो किस तरह का memory pressure समस्या बन रहा है, यह बताने से मदद मिलेगी। goref repo, वैसे Datadog continuous profiling पर काम कर रहा है और Go runtime profiling में लगातार योगदान भी दे रहा है।
  • यह जानने की जिज्ञासा है कि GC वाली language में "लगातार memory leak" कैसे होता है।
  • आदर्श रूप में मेरा मानना है कि दूसरी languages की तरह stack पर क्या रखा जाए इसे explicitly control करने की सुविधा होनी चाहिए थी (सिर्फ़ escape analysis पर भरोसा करने के बजाय)। अभी के लिए -gcflags -m=3 option या VSCode Go plugin में ui.codelenses, ui.diagnostic.annotations जैसी settings से काम चलाना पड़ता है, जो असुविधाजनक है।
  • "लगातार memory leak / memory pressure" के संदर्भ में, Go में goroutine बनाने के बाद अगर आपको उसका पक्का cleanup तरीका नहीं पता, तो उसे बनाना ही नहीं चाहिए।
  • pprof भी काफ़ी अच्छी तरह काम करता है, लेकिन आप उसमें कौन सी अतिरिक्त सुविधा चाहते हैं?
• यह कोशिश ठीक लगती है। अगर client request mechanism बदल जाए तो कुछ जोखिम है, लेकिन headers लगभग कभी नहीं बदलते (खासकर नए platform जोड़ने के अलावा)। Go सिर्फ़ amd64, arm64 को संभालता है, इसलिए समस्या कम है। इस सुधार का असली फ़ायदा memory leak रोकने से ज़्यादा uninitialized memory की सटीक पहचान में है। जब memory reuse होती है, तब अगर "poisoning" (जानबूझकर उसे उपयोग-अयोग्य चिह्नित करना) न हो, तो analysis कठिन हो जाता है। यह फीचर cachegrind, callgrind को छोड़कर बाकी tools में भी काफ़ी उपयोगी है।
• मुझे यह सुधार फ़ायदे से ज़्यादा Go ecosystem की एक छोटी-सी विफलता जैसा लगता है। मुझे Valgrind बहुत पसंद है और C developer के दिनों में मैं इसे अक्सर इस्तेमाल करता था। लेकिन यह तथ्य कि Go को भी Valgrind की ज़रूरत पड़ रही है, भाषा या ecosystem की कुछ कमियों की ओर इशारा करता है। मैंने लगभग 6 साल Rust इस्तेमाल किया है और कभी नहीं लगा कि Valgrind चाहिए (सिवाय एक बार जब टीम के किसी साथी ने इस्तेमाल किया था)। मुझे पता है कि यह भावना शायद cgo की वजह से है, फिर भी इसमें थोड़ा regression जैसा अहसास होता है।
  • यह समझना कठिन है कि Go से जुड़ी top comments में Rust का ज़िक्र तंज़ के साथ क्यों आ ही जाता है। इससे एक साथ रक्षात्मकता और श्रेष्ठताबोध दोनों झलकते हैं।
  • इस फीचर का मुख्य उद्देश्य सही memory tracking से ज़्यादा constant-time code testing में उपयोग करना है। संबंधित विवरण अभी भी थोड़ा प्रासंगिक है।
  • मैंने Rust में भी Valgrind का थोड़ा-बहुत उपयोग किया है। इसकी ज़रूरत बहुत बार नहीं पड़ती, लेकिन ज़रूरत होना पूरी तरह संभव है। Rust बहुत विविध environments में इस्तेमाल हो सकती है: high-level functional code से लेकर low-level C-जैसे microcontroller code तक। कहीं unsafe बिल्कुल नहीं होता, कहीं वह अनिवार्य होता है। FFI के ज़रिए C का उपयोग भी आम बात है, इसलिए कभी-न-कभी ज़रूरत पड़ सकती है। पहले जब मैं nginx के लिए Rust module बना रहा था (जब official/unofficial bindings नहीं थे), तब अक्सर गलतियाँ हो जाती थीं और Valgrind ने मदद की थी।
  • आप कितना unsafe code लिखते हैं, कितने unsafe crates या C/C++ libraries जोड़ते हैं, उसी पर उपयोग की आवृत्ति निर्भर करती है। Java, .NET, Node में भी external dependencies की वजह से ऐसी ज़रूरत पैदा हो सकती है।