6 ms·

For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://

by Maxious 9mo ago

For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 https://github.com/ghostty-org/ghostty/discussions/9962 but has not graduated to issue worthy status

quantummagic 9mo ago
That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
- mi_lk 9mo ago
  I’m sure they would appreciate a report as it doesn’t seem that it can be reproduced yet
- favflam 9mo ago
  btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
  - tynorf 9mo ago
    Chrome on my work laptop sits around 20-30GB all day every day.
    - typeofhuman 9mo ago
      I wonder if having less RAM would compel you to read, commit to long term memory, and then close those 80 tabs you have open.
      - transcriptase 9mo ago
        I wonder if a good public flogging would compel chrome and web devs to have 80 tabs take up far less than a gigabyte of memory like they should in a world where optimization wasn’t wholesale abandoned under the assumption that hardware improvements would compensate for their laziness and incompetence.
        refulgentis 9mo ago
        [flagged]
        abenga 9mo ago
        Is there a straightforward way to have one-process-per tab in browsers without using significant amounts (O(n_tabs)) of memory?
        samus 9mo ago
        There is no justification for that IMHO. The program text only needs to be in memory once. However, each process probably has its own instance of the JS engine, together with the website's heap data and the JIT-compiled code objects. That adds up.
        abenga 9mo ago
        I'd very much like a crash in one tab not to kill other tabs. And having per tab sandboxing would be more secure, no?
        samus 9mo ago
        What do you mean? All these features are provided by process per tab.
  - pdpi 9mo ago
    There's all the usual "$APPLICATION is a memory hog" complaints, for one. In the SWE world, dev servers are a luxury that you don't get in most companies, and most people use their laptops as workstations. Depending on your workflow, you might well have a bunch of VMs/containers running. Even outside of SWE world, people have plenty of use for more than 8GiB of RAM. Large Photoshop documents with loads of layers, a DAW with a bazillion plugins and samples, anything involving 4k video are all workloads that would struggle running on such a small RAM allowance.
    - gizmo686 9mo ago
      This depends on industry. Around here, working locally on laptop is a luxury, and most devs are required to treat their laptop like a thin client. Of course, being developer laptops, they all come with 16 gigs of RAM. In contrast, the remote VMs where we do all of the actual work are limited to 4GiB unless we get manager and IT approval for more.
      - sumanthvepa 9mo ago
        Interesting. I required all my devs to use local VMs for development. We've saved a fair bit on cloud costs.
        happymellon 9mo ago
        Current job used to let us run containers locally, but they decided to wrap initially docker, and then podman with "helper" scripts. These broke regularly, and became too much overhead to maintain so we are mandated to do local dev but access a dev k8 cluster to perform any level of testing that is more than unit and requires a db. A really shame as running local docker/podman for postges was fine when you just ran the commands.
        cdogl 9mo ago
        I find this quite surprising! What benefit does your org accrue by mandating that the db instance used for testing is centralised? Where I am, the tests simply assume that there’s a database available on a certain port. docker-compose.yml makes it easy to spin this up for those so inclined. At that stage it’s immaterial whether it’s running natively, or in docker, or forwarded from somewhere else. Our tests stump up all the data they need and tear down the db afterwards. In contrast, I imagine that a dev k8s cluster requires some management and would be a single point of failure.
  - afiori 9mo ago
    Browser + 2 vscode + 4 docker container + MS Teams + postman + MongoDB Compass Sure it is bloated, but it is the stack we have for local development
  - stackghost 9mo ago
    With 32 GB I can run two whole Electron applications! Discord and Slack! It's a life of luxury, I tell you.
  - samus 9mo ago
    Browsers can get quite bloated, especially if one is not in the habit of closing tabs or restarting it from time to time. IDEs, other development tools, and most Electron abominations are also not shy about guzzling memory.
  - nkrisc 9mo ago
    You asked if there is a justification and then in the same post justified why you need it.
    - favflam 9mo ago
      My post was about laptop RAM. I counted server-side RAM as a separate thing.
  - School-Cotton 9mo ago
    > But, I assume devs just do RAM heavy dev work on a server over ssh. This assumption is wrong. I compile stuff directly on my laptop, and so do a lot of other people. Also, even if nobody ran compilers locally, there is still stuff like rustc, clangd, etc. which take lots of RAM.
  - fastasucan 9mo ago
    >But, I assume devs just do RAM heavy dev work on a server over ssh. Why do you assume that? Its nice to do things locally sometimes. Maybe even while having a browser open. It doesn't take much to go over 8gb.
- mitchellh 9mo ago
  Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1. The report at hand seems to affect a very limited number of users (given the lack of reports and information about them). There are lots of X meme posts about Ghostty in the macOS "Force Close" window using a massive amount of RAM but that isn't directly useful because that window also reports all the RAM _child processes_ are using (e.g. if you run a command in your shell that consumes 100 GB of RAM, macOS reports it as Ghostty using 100 GB of RAM). And the window by itself also doesn't tell us what you were doing in Ghostty. It farms good engagement, though. 2. We've run Ghostty on Linux under Valgrind in a variety of configurations (the full GUI), we run all of Ghostty's unit tests under Valgrind in CI for every commit, and we've run Ghostty on macOS with the Xcode Instruments leak checker in a variety of configurations and we haven't yet been able to find any leaks. Both of these run fully clean. So, the "easy" tools can't find it. 3. Following point 1 and 2, no maintainer familiar with the codebase has ever seen leaky behavior. Some of us run a build of Ghostty, working full time in a terminal, for weeks, and memory is stable. 4. Our Discord has ~30K users, and within it, we only have one active user who periodically gets a large memory issue. They haven't been able to narrow this down to any specific reproduction and they aren't familiar enough with the codebase to debug it themselves, unfortunately. They're trying! To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users. That's why the discussion is open and we're soliciting input. I even spent about an hour today on the latest feedback (posted earlier today) trying to use that information to narrow it down. No dice, yet. If anyone has more info, we'd love to find this. :)
  - withinboredom 9mo ago
    Valgrind won’t show you leaks where you (or a GC) still holds a reference. This could mean you’re holding on to large chunks of memory that are still referenced in a closure or something. I don’t know what language or anything about your project, but if you’re using a GC language, make sure you disable GC when running with valgrind (a common mistake). You’ll see a ton of false positives that the GC would normally clean up for you, but some of those won’t be false positives.
hitekker 9mo ago
The author says in the first link he only heard it reported twice, which I'm guessing is the latter two links (the two discussions) Your second link looks like an X user trying to start a flamewar; the rest of the replies are hidden to me.
eapotapov 9mo ago
For those who have the issue. I reported the issue in discussions some time ago, but had no reaction/response. I was able to reproduce the leak consistently. Finally I've got all the reports done by me, Ghostty sources and Claude Code and tried to fix it. For the first couple of weeks there were no leaks at all, now it started again but only 1/10 of the times it was before. https://github.com/ghostty-org/ghostty/discussions/9786 https://github.com/ghostty-org/ghostty/discussions/9786 There are some logs and a Claude Code review md file that might be useful. Hope it will help someone investigate further.
timcobb 9mo ago
Seems like the contributors don't feel like it's clear enough yet to make an actionable issue and needs more discussion. Are you a contributor?
quotemstr 9mo ago
It's not clear to me why I'd want to use Ghostty over WezTern or Kitty, TBH. Ghostty is certainly trends on social media, but that's a negative signal for me.
NoGravitas 9mo ago
It can also be remarkably picky about GPUs, even otherwise well-supported integrated GPUs, but any discussion of this is declared a GTK problem (or an nvidia problem, even on intel).

by Maxious 9mo ago

quantummagic 9mo ago

That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.

mi_lk 9mo ago
I’m sure they would appreciate a report as it doesn’t seem that it can be reproduced yet
favflam 9mo ago
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
- tynorf 9mo ago
  Chrome on my work laptop sits around 20-30GB all day every day.
  - typeofhuman 9mo ago
    I wonder if having less RAM would compel you to read, commit to long term memory, and then close those 80 tabs you have open.
    - transcriptase 9mo ago
      I wonder if a good public flogging would compel chrome and web devs to have 80 tabs take up far less than a gigabyte of memory like they should in a world where optimization wasn’t wholesale abandoned under the assumption that hardware improvements would compensate for their laziness and incompetence.
      - refulgentis 9mo ago
        [flagged]
      - abenga 9mo ago
        Is there a straightforward way to have one-process-per tab in browsers without using significant amounts (O(n_tabs)) of memory?
        samus 9mo ago
        There is no justification for that IMHO. The program text only needs to be in memory once. However, each process probably has its own instance of the JS engine, together with the website's heap data and the JIT-compiled code objects. That adds up.
        abenga 9mo ago
        I'd very much like a crash in one tab not to kill other tabs. And having per tab sandboxing would be more secure, no?
        samus 9mo ago
        What do you mean? All these features are provided by process per tab.
- pdpi 9mo ago
  There's all the usual "$APPLICATION is a memory hog" complaints, for one. In the SWE world, dev servers are a luxury that you don't get in most companies, and most people use their laptops as workstations. Depending on your workflow, you might well have a bunch of VMs/containers running. Even outside of SWE world, people have plenty of use for more than 8GiB of RAM. Large Photoshop documents with loads of layers, a DAW with a bazillion plugins and samples, anything involving 4k video are all workloads that would struggle running on such a small RAM allowance.
  - gizmo686 9mo ago
    This depends on industry. Around here, working locally on laptop is a luxury, and most devs are required to treat their laptop like a thin client. Of course, being developer laptops, they all come with 16 gigs of RAM. In contrast, the remote VMs where we do all of the actual work are limited to 4GiB unless we get manager and IT approval for more.
    - sumanthvepa 9mo ago
      Interesting. I required all my devs to use local VMs for development. We've saved a fair bit on cloud costs.
      - happymellon 9mo ago
        Current job used to let us run containers locally, but they decided to wrap initially docker, and then podman with "helper" scripts. These broke regularly, and became too much overhead to maintain so we are mandated to do local dev but access a dev k8 cluster to perform any level of testing that is more than unit and requires a db. A really shame as running local docker/podman for postges was fine when you just ran the commands.
        cdogl 9mo ago
        I find this quite surprising! What benefit does your org accrue by mandating that the db instance used for testing is centralised? Where I am, the tests simply assume that there’s a database available on a certain port. docker-compose.yml makes it easy to spin this up for those so inclined. At that stage it’s immaterial whether it’s running natively, or in docker, or forwarded from somewhere else. Our tests stump up all the data they need and tear down the db afterwards. In contrast, I imagine that a dev k8s cluster requires some management and would be a single point of failure.
- afiori 9mo ago
  Browser + 2 vscode + 4 docker container + MS Teams + postman + MongoDB Compass Sure it is bloated, but it is the stack we have for local development
- stackghost 9mo ago
  With 32 GB I can run two whole Electron applications! Discord and Slack! It's a life of luxury, I tell you.
- samus 9mo ago
  Browsers can get quite bloated, especially if one is not in the habit of closing tabs or restarting it from time to time. IDEs, other development tools, and most Electron abominations are also not shy about guzzling memory.
- nkrisc 9mo ago
  You asked if there is a justification and then in the same post justified why you need it.
  - favflam 9mo ago
    My post was about laptop RAM. I counted server-side RAM as a separate thing.
- School-Cotton 9mo ago
  > But, I assume devs just do RAM heavy dev work on a server over ssh. This assumption is wrong. I compile stuff directly on my laptop, and so do a lot of other people. Also, even if nobody ran compilers locally, there is still stuff like rustc, clangd, etc. which take lots of RAM.
- fastasucan 9mo ago
  >But, I assume devs just do RAM heavy dev work on a server over ssh. Why do you assume that? Its nice to do things locally sometimes. Maybe even while having a browser open. It doesn't take much to go over 8gb.
mitchellh 9mo ago
Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1. The report at hand seems to affect a very limited number of users (given the lack of reports and information about them). There are lots of X meme posts about Ghostty in the macOS "Force Close" window using a massive amount of RAM but that isn't directly useful because that window also reports all the RAM _child processes_ are using (e.g. if you run a command in your shell that consumes 100 GB of RAM, macOS reports it as Ghostty using 100 GB of RAM). And the window by itself also doesn't tell us what you were doing in Ghostty. It farms good engagement, though. 2. We've run Ghostty on Linux under Valgrind in a variety of configurations (the full GUI), we run all of Ghostty's unit tests under Valgrind in CI for every commit, and we've run Ghostty on macOS with the Xcode Instruments leak checker in a variety of configurations and we haven't yet been able to find any leaks. Both of these run fully clean. So, the "easy" tools can't find it. 3. Following point 1 and 2, no maintainer familiar with the codebase has ever seen leaky behavior. Some of us run a build of Ghostty, working full time in a terminal, for weeks, and memory is stable. 4. Our Discord has ~30K users, and within it, we only have one active user who periodically gets a large memory issue. They haven't been able to narrow this down to any specific reproduction and they aren't familiar enough with the codebase to debug it themselves, unfortunately. They're trying! To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users. That's why the discussion is open and we're soliciting input. I even spent about an hour today on the latest feedback (posted earlier today) trying to use that information to narrow it down. No dice, yet. If anyone has more info, we'd love to find this. :)
- withinboredom 9mo ago
  Valgrind won’t show you leaks where you (or a GC) still holds a reference. This could mean you’re holding on to large chunks of memory that are still referenced in a closure or something. I don’t know what language or anything about your project, but if you’re using a GC language, make sure you disable GC when running with valgrind (a common mistake). You’ll see a ton of false positives that the GC would normally clean up for you, but some of those won’t be false positives.

hitekker 9mo ago

The author says in the first link he only heard it reported twice, which I'm guessing is the latter two links (the two discussions) Your second link looks like an X user trying to start a flamewar; the rest of the replies are hidden to me.

eapotapov 9mo ago

For those who have the issue. I reported the issue in discussions some time ago, but had no reaction/response. I was able to reproduce the leak consistently. Finally I've got all the reports done by me, Ghostty sources and Claude Code and tried to fix it. For the first couple of weeks there were no leaks at all, now it started again but only 1/10 of the times it was before. https://github.com/ghostty-org/ghostty/discussions/9786 https://github.com/ghostty-org/ghostty/discussions/9786 There are some logs and a Claude Code review md file that might be useful. Hope it will help someone investigate further.

timcobb 9mo ago

Seems like the contributors don't feel like it's clear enough yet to make an actionable issue and needs more discussion. Are you a contributor?

quotemstr 9mo ago

It's not clear to me why I'd want to use Ghostty over WezTern or Kitty, TBH. Ghostty is certainly trends on social media, but that's a negative signal for me.

NoGravitas 9mo ago

It can also be remarkably picky about GPUs, even otherwise well-supported integrated GPUs, but any discussion of this is declared a GTK problem (or an nvidia problem, even on intel).