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

 (mitchellh.com)
1 पॉइंट द्वारा GN⁺ 2026-01-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 ठीक करने की कुंजी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-11
Hacker News की राय

  • यह सचमुच बहुत अच्छी खबर है। इस समस्या को हल करने में शामिल सभी लोगों के लिए तालियां
    पिछले हफ्ते इस थ्रेड में इस बग का पहले ही ज़िक्र हो चुका था
    लगता है Claude Code ने इस बग को ज़्यादा यूज़र्स तक पहुंचाने में भूमिका निभाई, लेकिन मेरी तरह ऐसे लोग भी थे जिन्होंने Claude Code बिल्कुल इस्तेमाल नहीं किया था और फिर भी वही समस्या झेली
    किसी पेज को ‘non-standard’ के रूप में वर्गीकृत करने के मानदंड जितने लगते हैं, उससे कम काले-सफेद जैसे स्पष्ट नहीं हैं
    और मुझे लगता है कि scrollback-limit = 0 जैसी सेटिंग इस्तेमाल करने वालों के लिए यह लीक और ज़्यादा बार हुई होगी
    यह थोड़ा खलता है कि फ़िक्स का तरीका शायद गैर-ज़रूरी रूप से non-standard पेजों को हटाकर फिर से बना सकता है; क्या पहले से non-standard पुराने पेजों को दोबारा इस्तेमाल नहीं किया जा सकता था?

    • उस हिस्से पर ब्लॉग पोस्ट में पहले ही बात की गई थी
      PageList का व्यवहार पहले जैसा ही था, और बग के दौरान भी उसने सिर्फ़ क्षमता समायोजन के समय गलत आकार देखा था
      परफ़ॉर्मेंस के अनुभव में कोई बदलाव नहीं होगा
      सुझाए गए विकल्प पर भी विचार किया गया था, लेकिन मौजूदा तरीका benchmark data से पर्याप्त रूप से समर्थित है
      मैं भी अपना विचार बदल सकता हूं, लेकिन इस बार पूरी सोच बदलने के बजाय लीक फ़िक्स पर ध्यान रखा गया
    • यह अच्छी बात रही कि बीटा चरण में इस इश्यू को खोजकर रिपोर्ट किया जा सका
      वास्तव में यह segfault कराने वाला, reproducible bug था
    • वैसे, Claude Code की वजह से CLI फिर से आकर्षक लगने लगा है
      पिछले 20 सालों में किसी भी चीज़ ने CLI को इतना नया एहसास नहीं दिया
    • memory leak वाला थ्रेड यहां है

  • शानदार लेख था। Ghostty बनाने के लिए mitchellh का धन्यवाद
    मैंने पिछले साल इस पर स्विच किया था और एक बार भी पछतावा नहीं हुआ
    बस यह थोड़ा हैरान करने वाला था कि फ़िक्स कुछ महीनों बाद आने वाली feature release में शामिल होगा
    मुझे लगा था यह bugfix release में आएगा

    • यह पहले से ही नवीनतम nightly build में शामिल है

  • जैसे ही पेजों की बात आई, मैंने सोचा “अच्छा, यह memory pooling है”, फिर लगा “शायद ring buffer होगा”, और सच में यह scrollback reuse ही निकला
    बग कहां होगा, इसका भी तुरंत अंदाज़ा हो गया — वही हिस्सा जहां पेज मेमोरी ठीक से फ्री नहीं की गई थी
    memory alignment का डायग्राम भी बढ़िया था
    यह फिर याद दिलाता है कि हर नई कोशिश के साथ लीक की संभावना भी आती है

  • मैं इस हफ्ते Ghostty पर आया, और terminal UI app डेवलपमेंट के दौरान OOM crash झेला
    स्ट्रक्चर ऐसा था कि tab bar में UTF8 icons इस्तेमाल हो रहे थे, और terminal resize करते ही तुरंत crash हो जाता था
    इसे reproduce करना आसान था, इसलिए मैं bug report तैयार कर रहा था, लेकिन यह ब्लॉग पोस्ट में समझाई गई समस्या से बहुत मिलता-जुलता लग रहा है
    उम्मीद है कि यह हल हो जाएगा

  • मैंने @mitchellh से पूछा — memory visualization किस टूल से बनाई गई, और वेबसाइट मोबाइल पर भी अच्छी चल रही थी, तो stack कैसा है यह जानने की उत्सुकता है

    • Opus 4.5 से जनरेट की गई static HTML/CSS का इस्तेमाल किया गया
      visualization का कोड one-off था, इसलिए quality से ज़्यादा सिर्फ़ accuracy सत्यापित की गई
      हर ब्लॉग पोस्ट के लिए namespace अलग रखा जाता है और उसे दोबारा इस्तेमाल नहीं किया जाता
      बस यह देखा जाता है कि implementation कोई अजीब हरकत न करे (जैसे bitcoin mining, secret leak वगैरह)
      असली मकसद जानकारी देना है, और ऐसे डायग्राम चीज़ों को काफ़ी आसानी से समझने योग्य बना देते हैं

  • मैं Ghostty के विकास को लगातार देख रहा हूं
    इसमें थोड़ा overengineering का एहसास ज़रूर है, लेकिन इस तरह के bug postmortem शिल्पकला से प्रेम करने वालों के लिए बहुत कीमती सामग्री हैं

    • जानना चाहूंगा कि आपको किन मायनों में यह overengineering लगा

  • अगर यह Rust-based terminal होता, तो सोच रहा हूं कि ऐसी implementation performance loss के बिना कैसे की जाती

  • Ghostty या terminal emulator की गहरी जानकारी न होने पर भी यह लेख समझना आसान था
    इसकी accessibility और दोस्ताना व्याख्या प्रभावशाली थी

  • इससे फिर महसूस हुआ कि reproducible bug report कितनी महत्वपूर्ण होती है

  • मैं इंतज़ार कर रहा हूं कि कोई आकर कहे, “अगर Rust इस्तेमाल किया होता तो यह नहीं होता”

    • शायद लंबा इंतज़ार करना पड़े
      Rust भाषा स्तर पर ‘memory leak safety’ की गारंटी नहीं देता
      safe Rust code भी मेमोरी लीक कर सकता है — बस यह safety issue नहीं माना जाता
      standard API में भी Box::leak जैसी चीज़ें हैं जो स्पष्ट रूप से लीक की अनुमति देती हैं
      Rust बस अनचाहे leaks पैदा करना कठिन बनाता है, उन्हें पूरी तरह रोकता नहीं