Ghostty की सबसे बड़ी memory leak को खोजकर ठीक करना

• Ghostty terminal emulator में लंबे समय तक चलने पर दर्जनों GB memory घेर लेने वाली गंभीर leak समस्या पाई गई
• समस्या की जड़ PageList struct की non-standard memory page reuse logic में थी, जहाँ munmap कॉल नहीं होने से मुक्त न हुई memory जमा होती रही
• Claude Code CLI बार-बार multi-codepoint grapheme output बनाता है, जिससे non-standard page का उपयोग बढ़ा और leak बड़े पैमाने पर सामने आया
• fix में non-standard pages को reuse न करके तुरंत मुक्त करने के लिए बदलाव किया गया, और macOS की VM tag feature का उपयोग leak को trace और verify करने में किया गया
• इस fix को Ghostty की सबसे बड़ी leak समस्या का समाधान माना जा रहा है, और इसे आने वाले release (1.3) में शामिल किया जाएगा

---

Ghostty की memory leak का overview

• कुछ users ने रिपोर्ट किया कि Ghostty लंबे समय तक चलने के बाद 37GB से अधिक memory उपयोग कर रहा था
  • leak कम से कम version 1.0 से मौजूद थी, और हाल की CLI apps ने कुछ विशेष conditions पूरी करके इस समस्या को उजागर किया
• fix पहले ही GitHub में merge हो चुका है, और nightly builds तथा 1.3 stable release में शामिल होगा

PageList structure और memory management का तरीका

• Ghostty terminal content को स्टोर करने के लिए PageList नाम की doubly linked list structure का उपयोग करता है
  • हर page में characters, styles, hyperlinks आदि का data होता है
• pages को mmap से allocate किया जाता है, और standard-size page pool के ज़रिए reuse किया जाता है
  • standard size या उससे छोटे pages pool में वापस कर दिए जाते हैं
  • non-standard size pages को सीधे munmap से मुक्त करना होता है
• यह structure अपने आप में सही है, लेकिन optimization logic के bug की वजह से leak हुई

Scrollback optimization और bug का कारण

• Ghostty, scrollback-limit पार होने पर सबसे पुराने page को reuse करने वाला optimization करता है
  • नया page allocate किए बिना सिर्फ pointers बदलकर performance बेहतर होती है
• समस्या यह थी कि इस प्रक्रिया में non-standard page का सिर्फ metadata standard size में बदला गया, जबकि वास्तविक memory वैसी ही रही
  • बाद में मुक्त करते समय उसे standard page समझ लिया गया, इसलिए munmap कॉल ही नहीं हुआ
• इसके कारण non-standard pages मुक्त हुए बिना जमा होते गए, और लंबे runtime में बड़े पैमाने की memory leak हुई

Claude Code और leak का बड़े पैमाने पर सामने आना

• Claude Code CLI अक्सर multi-codepoint grapheme output बनाता है, जिससे non-standard page usage बढ़ गया
  • इसके अलावा scrollback output भी बहुत होने से leak तेज़ी से जमा हुई
• Ghostty की design में non-standard pages का होना दुर्लभ होना चाहिए, लेकिन Claude Code की प्रकृति के कारण leak बड़े पैमाने पर reproduce हुई
• developer ने स्पष्ट किया कि यह bug Claude Code की समस्या नहीं, बल्कि Ghostty की internal logic की कमी है

क्या बदला गया

• समाधान यह था कि non-standard pages को reuse न किया जाए और तुरंत munmap किया जाए
  • scrollback के दौरान non-standard page मिलने पर pool से नया standard page फिर से allocate किया जाता है
• कुछ users ने non-standard page reuse strategy का सुझाव दिया, लेकिन फिलहाल सरल और सुरक्षित fix को प्राथमिकता दी गई
• fix code उदाहरण:

  if (first.data.memory.len > std_size) {
      self.destroyNode(first);
      break :prune;
  }
  

VM tag का उपयोग करके leak trace करना

• macOS के Mach kernel VM tag feature का उपयोग करके PageList memory allocations को विशेष tag दिया गया
  • debugging के समय Ghostty के memory regions को साफ़ तौर पर पहचाना जा सकता है
  • leak के कारण को trace करने और fix verify करने में इससे बड़ी मदद मिली
• इस feature से PageList से जुड़ी memory के मुक्त होने या न होने को visual तौर पर जांचना संभव हुआ

Ghostty की memory leak prevention व्यवस्था

• Ghostty कई तरीकों से leak को detect और prevent करता है
  • debug builds और unit tests में Zig का leak-detecting allocator उपयोग होता है
  • CI में valgrind से पूरा test suite चलाया जाता है
  • macOS Instruments से Swift code leak checks किए जाते हैं
  • GTK से जुड़े PRs को Valgrind GUI tests से verify किया जाता है
• यह leak सिर्फ खास conditions में होती थी, इसलिए मौजूदा tests में reproduce नहीं हो पाई
  • नया test case जोड़ दिया गया है ताकि regression को रोका जा सके

निष्कर्ष

• यह मामला Ghostty में अब तक की सबसे बड़ी memory leak के रूप में सामने आया
• fix के बाद भी user reports और reproduction tests के ज़रिए लगातार monitoring की जाएगी
• community द्वारा दिए गए diagnostic data और reproduction cases ने समस्या हल करने में निर्णायक भूमिका निभाई
• यह फिर रेखांकित हुआ कि reproducible environment memory leak ठीक करने की कुंजी है