Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finding and fixing Ghostty's largest memory leak

mitchellh.com

Post reply on HN
Print view View original

81–90 of 152 posts

Re: Finding and fixing Ghostty's largest memory leak

#81

Post by llmslave3 »

I hate to say it, but this probably would not have happened in a garbage collected language.

GC languages are fast these days. If you don't want a runtime like C# (which has excellent performance) a language like Go would have worked just fine here, compiling to a small native binary but with a GC.

I don't really understand the aversion to GC's. In memory constrained scenarios or where performance is an absolute top priority, I understand wanting manual control. But that seems like a very rare scenario in user space.

Re: Finding and fixing Ghostty's largest memory leak

#82

Post by mariusor »

ComputerGuru wrote: post #74

The number of people here on HN gaslighting those that said they ran into this bug an challenging them to prove it was real..

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.

Re: Finding and fixing Ghostty's largest memory leak

#85

Post by dnautics »

hardwaresofton wrote: post #80
vlovich123 wrote: post #63

Earlier quoted context omitted.

The issue isn’t linked list vs dequeue but type confusion about what was in the container. They didn’t forget to drop it - they got confused about which type was in the list when popping and returned it to the pool instead of munmap. The way to solve this in Rust would be to put this logic in the drop and hide each page type in an enum. That way you can’t ever confuse the types or what happens when you drop.

Was going to say this, but I don't think anyone actually wants to hear that Rust actually would have helped here. As you're saying, the bug was the equivalent of an incorrectly written Drop implementation. Nothing against Zig, and people not using Rust is just fine, but this is what happens when you want C-like feel for your language. You miss out on useful abstractions along with the superfluous ones. "We don't need…

I don't know if this particular error would have been findable with zig-clr, but you don't need RAII. Errdefer/defer is enough, if you have an alogrithm checking your work.

Re: Finding and fixing Ghostty's largest memory leak

#86

Post by AndyKelley »

hardwaresofton wrote: post #80
vlovich123 wrote: post #63

Earlier quoted context omitted.

The issue isn’t linked list vs dequeue but type confusion about what was in the container. They didn’t forget to drop it - they got confused about which type was in the list when popping and returned it to the pool instead of munmap. The way to solve this in Rust would be to put this logic in the drop and hide each page type in an enum. That way you can’t ever confuse the types or what happens when you drop.

Was going to say this, but I don't think anyone actually wants to hear that Rust actually would have helped here. As you're saying, the bug was the equivalent of an incorrectly written Drop implementation. Nothing against Zig, and people not using Rust is just fine, but this is what happens when you want C-like feel for your language. You miss out on useful abstractions along with the superfluous ones. "We don't need…

If you wanted to match Ghostty's performance in Rust, you'd need to use unsafe in order to use these memory mapping APIs, then you'd be in the exact same boat. Actually you'd be in a worse boat because Zig is safer than unsafe Rust.

Re: Finding and fixing Ghostty's largest memory leak

#88

Post by p-e-w »

llmslave3 wrote: post #81

I hate to say it, but this probably would not have happened in a garbage collected language. GC languages are fast these days. If you don't want a runtime like C# (which has excellent performance) a language like Go would have worked just fine here, compiling to a small native binary but with a GC. I don't really understand the aversion to GC's. In memory constrained scenarios or where performance is an absolute top…

I agree that garbage collection is fine and Go indeed has an amazing garbage collector. Unfortunately, it also has the worst type system of all mainstream languages created in the 21st century, so the benefits are rarely worth the drawbacks.

Re: Finding and fixing Ghostty's largest memory leak

#89

Post by Maxious »

macote wrote: post #23
quantummagic wrote: post #2

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 bl…

The thread about memory leak is here: https://news.ycombinator.com/item?id=46461061

And the same diagnosis in the blog post was reported by a user in discussions a month ago but ignored https://github.com/ghostty-org/ghostty/discussions/9786#disc...

Re: Finding and fixing Ghostty's largest memory leak

#90

Post by Maxious »

mariusor wrote: post #82
ComputerGuru wrote: post #74

The number of people here on HN gaslighting those that said they ran into this bug an challenging them to prove it was real..

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.

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
Post reply on HN