[HN Gopher] Finding and fixing Ghostty's largest memory leak
___________________________________________________________________
Finding and fixing Ghostty's largest memory leak
Author : thorel
Score : 106 points
Date : 2026-01-10 18:58 UTC (4 hours ago)
(HTM) web link (mitchellh.com)
(TXT) w3m dump (mitchellh.com)
| quantummagic wrote:
| This is great news! Well done to everyone who helped sort it out.
| It was a problem noted by users in a thread here just last week,
| https://news.ycombinator.com/item?id=46460319
|
| While Claude Code might have been the reason this bug became
| triggered by more people, there are some of us who were hitting
| it without ever having used Claude Code at all. Maybe the
| assumption about what makes a page non-standard, isn't as black-
| and-white as presumed. And I wonder if the leak would have been
| triggered more often for people who use scrollback-limit = 0, or
| something very small.
|
| Probably not a huge deal, but it does seem the fix will
| needlessly delete and recreate non-standard pages in the case
| where the new page needs to be non-standard, and the oldest one
| (that needs to be pruned) already is non-standard and could be
| reused.
| mitchellh wrote:
| > Probably not a huge deal, but it does seem the fix will
| needlessly delete and recreate non-standard pages in the case
| where the new page needs to be non-standard, and the oldest one
| (that needs to be pruned) already is non-standard and could be
| reused.
|
| This is addressed in the blog post.
|
| It is how the PageList has always worked, and also how it
| worked before with the bug, because during capacity adjustment
| we would see the wrong size. This shouldn't change any
| perceived performance.
|
| And as I note in the blog post, there are alternative
| approaches such as the one you suggested, but we don't have
| enough empirical data to support changing our viewpoint on that
| whereas our current viewpoint (standard sizes are common) is
| well supported by known benchmarks. I'm open to changing my
| mind here, but I didn't want to change worldviews AND fix the
| leak in the same go.
| macote wrote:
| The thread about memory leak is here:
| https://news.ycombinator.com/item?id=46461061
| kepano wrote:
| Reliable reproductions are so valuable.
| LgWoodenBadger wrote:
| The contrast between the attitude here
| https://news.ycombinator.com/item?id=46461860 and in this story
| is a bit wacky to me.
| mitchellh wrote:
| What contrast? I stand by what I said there. I just re-read
| every point and I would say the same thing today and I don't
| think my blog post contradicts any of that?
|
| A user came along and provided a reliable reproduction for me
| (last night) that allowed me to find and fix the issue.
| Simultaneously they found the same thing and produced a similar
| fix, which also helped validate both our approaches. So, we
| were able to move forward. I said in the linked comment that I
| believed the leak existed, just couldn't find it.
|
| It also was fairly limited in impact. As far as Ghostty bugs
| go, the number of upvotes the bug report had (9) is very small.
| The "largest" in the title is with regards to the size of the
| leak in bytes, not the size of the leak in terms of reach.
|
| As extra data to support this, this bug has existed for at
| least 3 years (since the introduction of this data structure in
| Ghostty during the private beta). The first time I even heard
| about it in a way where I can confidently say it was this was
| maybe 3 or 4 months ago. It was extremely rare. I think the
| recent rise in popularity of Claude Code in particular was
| bringing this to the surface more often, but never to the point
| it rose to a massively reported issue.
| 1a527dd5 wrote:
| [flagged]
| mitchellh wrote:
| Discussion upvotes, discussion activity, and Discord
| reorts. I read every discussion and have been doing this
| project specifically for a few years now. There is a stark
| difference between a widespread and common bug and
| something like this.
|
| Like I said, this bug has existed for 3 years at this point
| and Ghostty is likely used by hundreds of thousands if not
| a million+ people daily (we don't have any analytics at all
| but have some side signals based on terminal reports from
| 3rd party CLIs). Trust me when I say that when there is a
| widespread issue, we hear it MUCH more loudly. :)
| masklinn wrote:
| Dupes are not deleted, you can just search for them and see
| that there are not that many of those, and that's with this
| not being the only unsolved memory leak
| (https://github.com/ghostty-org/ghostty/discussions/9314 is
| a different one).
| dang wrote:
| Could you please follow the HN guidelines when posting
| here? They include " _assume good faith._ " and " _don 't
| cross-examine_".
|
| https://news.ycombinator.com/newsguidelines.html
| 1a527dd5 wrote:
| Will do my best :)
| dang wrote:
| Appreciated!
| masklinn wrote:
| Not really? In your link TFAA was saying they were convinced an
| issue existed but the number of impacted users was limited, no
| maintainer experienced the issue, and they had no reproducer.
| As of yesterday TFAA still had no working reproducer:
| https://github.com/ghostty-org/ghostty/discussions/9962#disc...
|
| In the meantime they apparently got one (edit: per their
| sibling comment they got it yesterday evening) and were finally
| able to figure out the issue.
|
| edit: https://github.com/ghostty-org/ghostty/discussions/10244
| is where it was cracked.
| IshKebab wrote:
| Presumably that discussion is the reason this was fixed. Very
| bizarre bug tracking policy IMO.
| masklinn wrote:
| No, the reason it was fixed is that somebody managed to
| reliably reproduce the issue: https://github.com/ghostty-
| org/ghostty/discussions/10244
|
| As you can see, there's no hint or evidence they even are on
| HN let alone saw that discussion.
| resonious wrote:
| I think there's only a perceptible "attitude" difference if you
| are fired up by the fact that they are conservative about using
| the "issues" tab.
| darkteflon wrote:
| Super weird take. Why treat the guy as if he's a bad actor? All
| of the public evidence shows good faith on this issue and on
| the project in general. We've also had a clear explanation of
| why discussion precedes issue creation.
| dang wrote:
| " _Please respond to the strongest plausible interpretation of
| what someone says, not a weaker one that 's easier to
| criticize. Assume good faith._"
|
| https://news.ycombinator.com/newsguidelines.html
| txdv wrote:
| Only contrast I see is that he thought it was much more of a
| corner case which turned out to be not that true anymore since
| everyone started using claude code.
| lateral_cloud wrote:
| There are some really strange people on HN.
| hotpotat wrote:
| @mitchellh what did you use for the memory visualizations? Looks
| nice, and the website plays well with mobile. Whats the stack?
| mitchellh wrote:
| Static HTML/CSS generated by Opus 4.5.
|
| I like using AI for visualizations because it is one-time use
| throwaway code, so the quality doesn't matter at all (above not
| being TOTALLY stupid), it doesn't need to be maintained. I
| review the end result carefully for correctness because it's on
| a topic I'm an expert of.
|
| I produce non-reusable diagrams namespaced by blog post (so
| they're never used by any other post). I just sanity check that
| the implementation isn't like... mining bitcoin or leaking
| secrets (my personal site has no secrets to build) or
| something. After that, I don't care at all about that quality.
|
| The information is conveys is the critical part, and diagrams
| like this make it so much more consumable for people.
| hotpotat wrote:
| That's reasonable, thanks!
| 63 wrote:
| That's really cool. I was looking at them and thinking "I
| could probably make these with vanilla html/css but it'd be
| pretty tedious." Perfect use case for AI. I need to work on
| developing a reflex for it.
| mjn wrote:
| I've also started doing this, and it's surprisingly
| enjoyable to both do and even to read. The end result is
| often more readable to me than using a 3rd-party JS
| visualization library, because I only need to know standard
| HTML/CSS concepts to understand what's going on. And a side
| benefit is smaller pages with less bitrot due to being able
| to skip the dependencies.
| hotpotat wrote:
| speaking of claude code in Ghostty, I've noticed I can't drag and
| drop images into the prompt when the session is within a tmux
| pane. I miss that, coming from the mac terminal app, which
| allowed me to do so. I'd be willing to look into this myself, but
| mention it in case someone already knows where to start looking.
| bryancoxwell wrote:
| Super accessible write up as someone unfamiliar with Ghostty and
| terminal emulators in general. Thanks!
| jrpelkonen wrote:
| Great write-up. And, thanks mitchellh for Ghostty, I switched to
| it last year, and have not regretted it.
|
| However, I am a somewhat surprised that the fix is reserved for a
| feature release in a couple of months. I would have expected this
| to be included in a bug fix release.
| neobrain wrote:
| Funny timing, I moved to Ghostty this week and just today I ran
| into OOM crashes in Ghostty while developing a terminal UI app.
| Coincidentally this TUI has a tab bar that looks like this, where
| each UTF8 icons are used for recognizability and activity
| indicators (using (c) and EUR as placeholders here):
| 1|Flakes (c) 2|Installed (c) 3|Store (c) EUR 4|Security (c)
| EUR
| -----------------------------------------------------------
|
| This works fine normally, but resizing the terminal would quickly
| trigger the crash - easy to avoid but still annoying!
|
| I was already preparing myself to file a bug report with the easy
| repro, but this sounds suspiciously close to what the blog post
| is describing. Fingers crossed :)
|
| (EDIT: HN filters unicode, booo :( )
| Neywiny wrote:
| I don't understand why that is the preferred fix. I would have
| solved it other ways:
|
| 1. When resizing the page, leave some flag of how it was
| allocated. This tagging is commonly done as the always 0 bits in
| size or address fields to save space.
|
| 2. Since the pool is a known size of contiguous memory, check if
| the memory to be freed is within that range
|
| 3. Make the size immutable. If you want to realloc, go for it,
| and have the memory manager handle that boundary for you.
|
| Both of those not only maintain functionality which seems to have
| been lost with the feature reduction but also are more future
| proof to any other changes in size.
| drob518 wrote:
| Why not just use a circular buffer for the scroll back? Why use
| blocks at all if you're just going to recycle them anyway? That
| said, great write-up.
| dangoodmanUT wrote:
| waiting for someone to say "this wouldn't have happen if you
| chose rust"
___________________________________________________________________
(page generated 2026-01-10 23:00 UTC)