| > I hope one day you can. :) It seems unlikely given this exchange, as you seem to have decided to be as unhelpful as possible. > Before, when I killed Firefox (before it crashes naturally, of course), my committed memory would drop from 38GiB to around 18GiB, so uhh, unless some other app is intentionally playing with me and syncing up its memory leaks with Firefox's existence... From the article: > However, we have no control over Windows system libraries and in particular graphics drivers. One thing we noticed is that graphics drivers commit memory to make room for textures in system memory. Guess what's going to create textures which might trigger such an issue? The browser's hardware acceleration. Guess what happens to browser's textures when the browser is killed? They're freed. Might be a bug in Firefox, might be a bug in the crash reporter, might be a bug in the driver, might be that chromium is not using hardware acceleration. But here you have a mozilla engineer specifically working on crashes, and instead of trying to work with them (possibly off-board) and with the data they have to diagnose the issue — because I'd assume when gsvelto talks about commit space contents that's what they see in the crash reports - you're just being a snarky asshole. |
I'm not being unhelpful on purpose. They are just giving me answers that do not solve my problem. My problem is "Firefox requires overcommit to run for long periods of time ... because it has a memory leak". The solution to this problem is to figure out where the memory leak is coming from, and fix it, right? Not just to add more memory, even if it is only virtual memory.
> Guess what's going to create textures which might trigger such an issue? The browser's hardware acceleration. Guess what happens to browser's textures when the browser is killed? They're freed.
You just described a memory leak, yes, the exact issue that I am experiencing.
> Might be a bug in Firefox, might be a bug in the crash reporter, might be a bug in the driver, might be that chromium is not using hardware acceleration.
Well, I don't think the crash reporter or Chromium are at fault. And I know Chromium is using hardware acceleration because if I choose the d3d11 backend then Netflix goes black in screenshots due to DRM. So, if it is a graphics issue, it's something that Firefox does and Chromium does not. Which leaves Firefox bugs, or bugs in the driver that only Firefox triggers.
> But here you have a mozilla engineer specifically working on crashes, and instead of trying to work with them (possibly off-board) and with the data they have to diagnose the issue — because I'd assume when gsvelto talks about commit space contents that's what they see in the crash reports - you're just being a snarky asshole.
I'm sorry that I came off as a snarky asshole and that wasn't really my intention. I've been dealing with this issue for months, and as a result of that there is a lack of effort from me and that probably shows. I am sorry.
I would like to perform some more experiments to figure out what the issue is, but the problem is that when Firefox runs out of memory it also crashes half the other things on my system, which makes it dangerous.