Top
Best
New

Posted by thorel 1/10/2026

Finding and fixing Ghostty's largest memory leak(mitchellh.com)
632 points | 138 commentspage 3
cyh555 1/11/2026|
I wonder how a Rust-based terminal implements this without sacrificing performance.
0xbrayo 1/11/2026|
Someone check out alacritty source code and answer it for us
rrgok 1/11/2026||
Ask Claude Code about it using Ghostty without this fix ;)
sean_pedersen 1/11/2026||
Would this kind of bug have been catched by the Rust compiler?
autarch 1/11/2026|
I was wondering about this myself. My guess is no, since AFAIK the only way to do this sort manual memory management is to use unsafe code. But there's also things like the (bumpalo)[https://docs.rs/bumpalo/latest/bumpalo] crate in Rust, so maybe you wouldn't need to do this sort of thing by hand, in which case you're as leak-free as the bumpalo crate.
gfyhthgyrfg 1/11/2026||
[dead]
LgWoodenBadger 1/10/2026||
The contrast between the attitude here https://news.ycombinator.com/item?id=46461860 and in this story is a bit wacky to me.
mitchellh 1/10/2026||
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 1/10/2026||
[flagged]
mitchellh 1/10/2026|||
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. :)

dang 1/10/2026||||
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 1/10/2026||
Will do my best :)
dang 1/10/2026||
Appreciated!
masklinn 1/10/2026|||
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).
masklinn 1/10/2026|||
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.

resonious 1/10/2026|||
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.
lateral_cloud 1/10/2026|||
There are some really strange people on HN.
esseph 1/10/2026||
I sure hope so!
darkteflon 1/10/2026|||
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 1/10/2026|||
"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 1/10/2026|||
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.
IshKebab 1/10/2026||
Presumably that discussion is the reason this was fixed. Very bizarre bug tracking policy IMO.
masklinn 1/10/2026||
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.

vegabook 1/10/2026||
[flagged]
rvz 1/11/2026||
[flagged]
cyberax 1/10/2026||
Ugh. Is it just me, or is anyone else feeling a tad uncomfortable that their terminal app needs a custom memory allocator that mucks with low-level page tags?
flumpcakes 1/10/2026||
I am not sure on what your commented is based on, but in short: No? High performance software needs to deal with memory, and optimisations often will need some kind of direct control - as in this example where re-using memory is more performant than constantly churning with mmap.
sequin 1/11/2026||
I honestly don't understand why a terminal emulator needs to be performant. Seems like peak bikeshedding to me.
yoyohello13 1/11/2026|||
A lot of developers use the terminal as their primary interaction with the computer. Nvim, tmux, etc. Having it be fast is an extreme quality of life improvement. For devs who only ever use the terminal integrated into their ide then it’s probably less important.
cbmuser 1/11/2026||
Can you elaborate on that a bit, please?

I have never found myself in the situation where my terminal emulator would be too slow and I‘m using it for the majority of my day-to-day work.

I honestly never ran into a situation where I would habe blamed the terminal emulator for being too slow.

dkdcio 1/11/2026|||
not the same person but in the flow of doing things those little pauses (tens of milliseconds) do matter. I open/close nvim (and less-so tmux) a ton, and run lots of commands per day. I don’t want to wait

and once you get used to things being that fast, it’s hard to go back (analogous to what people say about high-refresh screens/monitors)

all that said the speed of the default mac terminal (and other emulators I tried) was always fine for me, performance was not why I switched to Ghostty

barnabee 1/11/2026|||
I think this kind of thing just bothers some people and not others.

I first started to understand and notice update rates and responsiveness as a gamer playing 1st person shooters.

I hate (ok, I find it a bit jarring) the jerky scrolling of a phone in battery save mode limited to 60(?) FPS. It’s so obviously not connected to your touch anymore.

In terminals it’s things like the responsiveness fuzzy finders and scrolling that I really notice.

I turn off animations everywhere I can.

It’s not impossible to use something slower, but when everything feels instant it’s just much more pleasant, smoother, and feels more productive as a result of the computer working at whatever speed my brain does.

drob518 1/11/2026||||
Well, perhaps “performant” isn’t the word you should be using. All code should be performant, where performant is defined as performing at an acceptable level. You might be tempted to then ask if it needs to be ultra high performance? That’s a better question but still off the mark. The correct question is whether YOU need an ultra high performance terminal emulator? If you don’t, you’re free to not use it. I haven’t found a need for it myself, for instance, and I still use the vanilla MacOS term. But that doesn’t mean someone else hasn’t wanted a faster term than the MacOS term and I wouldn’t throw shade on them for scratching that itch, even if I don’t share it.
RickHull 1/11/2026||||
https://ghostty.org/docs/about

> Ghostty is a terminal emulator that differentiates itself by being fast, feature-rich, and native. While there are many excellent terminal emulators available, they all force you to choose between speed, features, or native UIs. Ghostty provides all three.

> In all categories, I am not trying to claim that Ghostty is the best (i.e. the fastest, most feature-rich, or most native). But when I set out to create Ghostty, I felt all terminals made you choose at most two of these categories. I wanted to create a terminal that was competitive in all three categories and I believe Ghostty achieves that goal.

> Before diving into the details, I also want to note that Ghostty is a passion project started by Mitchell Hashimoto (that's me!). It's something I work on in my free time and is a labor of love. Please don't forget this when interacting with the project. I'm doing my best to make something great along with the lovely contributors, but it's not a full-time job for any of us.

homebrewer 1/11/2026||||
Scrolling and searching through megabytes of output is often useful. Sometimes you don't expect it and can't prepare for it in advance.
syntheticnature 1/11/2026||||
You've missed all the posts where people complain about a terminal emulator taking 1ms longer to respond to a keystroke than their preferred one, haven't you?
usertty 1/11/2026|||
I also didnt get it until I tried ghostty and saw the results of the command appear before even taking my finger off the enter key
speed_spread 1/11/2026|||
You're not alone. Correctness first. Such complicated schemes should be backed with repeatable benchmarks so that their purported gains can be challenged later by simpler techniques. Too often clever optimizations with marginal gains make it to production and become maintenance liabilities.
yoyohello13 1/11/2026||
Frankly, I wish more software prioritized performance this much.
ComputerGuru 1/11/2026||
The number of people here on HN gaslighting those that said they ran into this bug an challenging them to prove it was real..
mariusor 1/11/2026|
As you could see from TFA, getting a reliable reproduction case was the tricky part of fixing this bug, so "asking to prove it's real" is just a mean way of saying asking for reproduction steps, not gaslighting.
Maxious 1/11/2026||
It only took using claude code or other emoji heavy apps to reproduce and the memory grows linearly over time https://github.com/ghostty-org/ghostty/discussions/9786
mariusor 1/11/2026||
"only"... I don't think that means what you think it means in this context.
gethly 1/11/2026|
Should have used Odin instead of Zig.
tialaramex 1/11/2026|
How exactly would using a different unfinished programming language have helped?
More comments...