Hacker Newsnew | past | comments | ask | show | jobs | submit | gcp's commentslogin

I don't think Firefox has the access permissions needed to read MCE status, and the vast majority of our users don't have ECC, let alone they're going to run memtest86(+) after a Firefox crash.

If they did, we wouldn't be having this discussion to begin with!


No.


Deduplicating and identifying the source of a crash point is surprisingly hard, to the point that “it’s the only crash of its kind” could be a bug in your logic for linking issues.

This is a bit vague to really reply to very specifically, but yes, this is hard. Which is why quite some people work in this area. It's rather valuable to do so at Firefox-scale.

Even if the majority of time it generates the “same” failure mode, it can still sporadically generate a rare execution trace.

This doesn't matter that much because the "same" failure mode already allows you to see the bug and fix it.


Did you actually read the posts that started this topic, or are you being an ass for no reason?

Hint: No-one is claiming memory is to blame for 100% of the Firefox crashes. No-one is claiming it's 99% either.


Which part of my post was being an ass?

Sorry, but I experienced first hand Firefox's memory leaks not being taken seriously. This "bitflips" news is just released, but I fully expect anybody complaining about Firefox crashes to be met with low effort "It's your RAM," responses for the next few years now.


I'm quite confident to say that millions of people use Firefox to comment on Reddit or similar sites every day, or write long posts, without seeing this problem.

Without knowing more about your configuration, it's hard to give advice, but definitely worth trying with a clean profile first.

If you don't report this problem upstream it will never get fixed, as obviously no-one else is seeing this. Firefox has a built-in profiler that you can use to report performance problems like this.


You were seeing issues from the graphics driver, not Firefox.

Any memory allocation failing within the browser forces an instant crash unless the callsite explicitly opts in to handling the allocation failure.

"Check malloc failure" is an opt-out feature in browsers, not opt-in. It's the same in Chromium. Failing to check would cause too many security issues. (One more reason new stuff tends to prefer Rust, etc)


Thanks for the info! I guess it also makes sense as I realized after posting, if it did use the result of malloc unused it should crash immediately due to references into the zero page segment, thus can't have been what I saw.


Yeah, Dark Reader is known to totally plummet Firefox performance.

Not sure if it's a coding issue in the Firefox version of Dark Reader, or it's hitting some slow path in Firefox itself.


It helps if you file bugs in Bugzilla. You can link to them here, there's a good chance a developer will find them.


Change tends to mean things like exciting new spying and UI regressions

Or missing out on new anti-fingerprinting and anti-tracking improvements. Note that adblockers don't generally do the former.


The whole point of the about:restartrequired warning is to avoid this problem. If you're crashing, I hope you've been filing bugs.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: