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

I think that if you hit the crash in the same line of code many times, you can safely assume it's your own bug and not a memory issue.

If it's only hit once by a random person, memory starts being more likely.

(Unless that LOC is scanning memory or smth)


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.

Also, in an unsafe language all bets are off. A memory clobber, UAF or race condition can generate quite strange and ephemeral crashes. Even if the majority of time it generates the “same” failure mode, it can still sporadically generate a rare execution trace. It’s best to stop thinking of these as deterministic processes and more as a distribution of possible outcomes.


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.


If the crash is isolated (no other reports) and flipping one bit in the crashing pointer value would make the pointer valid, it's assumed to be a bitflip. This obviously will only catch a minor portion of bitflips, i.e. any image or video data with bitflips wouldn't crash.

From what he's saying they run an actual memory test after a crash, too.


If this were so all devs for apps, games, etc... would be talking about this but since this is the first time I'm hearing about this I'm seriously doubting this.

But they have?


What's the expected behavior of a JavaScript program that allocates all memory on the machine?


Browser killing the tab way before it happens


I'm pretty sure I saw them present on exactly this at FOSDEM?


Wordfeud uses a different board layout.


It's awfully close though


has had basic support merged

I read the parent post as saying that this is the problem, i.e. that "complete" support is a mess, because AFAIK even the reference implementation is incomplete and buggy, and that then getting angry at the consumers of it is besides the point and won't lead anywhere (which is what we see in practice).

Browsers supporting a format "a little" is almost worse than not supporting it at all, because it makes the compatibility and interoperability problems worse.


Are there any small engines that have enough of the web implemented that they can run it?


The only other (semi) alive browser engine today is Servo, originally by Mozilla (and the reason Rust was created for), which is these days a Linux Foundation project funded by Igalia.

There are small web engines anymore. Every other one, from khtml to presto to trident, is dead.


Opera?


Opera uses Chromium so it's covered under Blink/V8.


Presto hasn't been used for years


The Tauri app just uses the system WKWebView. Memory usage can be misleading due to reporting, see e.g. https://github.com/tauri-apps/tauri/issues/5889


Yeah not sure how it qualifies as lightweight...


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

Search: