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

Everything Is Broken: Shipping Rust-Minidump at Mozilla

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#41

Post by tedmielczarek »

cmrdporcupine wrote: post #35

Huh, wow, I used breakpad/minidumps daily when I was at Google working on Chromecast based things. I had no idea it existed outside that ecosystem. Now I know there's nice Rusty work happening with this stuff that I could maybe make use of for my next employer or a personal project. Neat.

I integrated Breakpad into Firefox to replace the old closed-source Talkback implementation, we shipped it in Firefox 3. I suspect (but would have to ask Mark Mentovai to confirm) that Breakpad was probably written for use in the not-yet-publicly-announced Chrome. If so, that would mean that we shipped it first. :) I probably still have commit access to Breakpad, although I haven't contributed to it in years.

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#42

Post by tedmielczarek »

structural wrote: post #8
secondcoming wrote: post #4

Maybe I'm missing something, but they ported from C++ (because 'C++ is bad donchaknow') to Rust and still ran into problems parsing crash dumps? If the dump is corrupt then just stop trying to parse/make sense of it; it's garbage.

This is the excessively fun part of dealing with crash dumps in general. Many of them are going to be 1% corrupt, 99% fine, and somewhere in them likely has vital information about what caused the corruption. So the entire reason for being for things like rust-minidump are to make enough sense out of files that are known to be corrupt garbage to be able to find bugs.

A lot of the weird bits in the Breakpad codebase were definitely from us finding extremely broken minidumps from Firefox users in the wild and then me tweaking the code to see if we could get something out of it so we had a chance at diagnosing the issue.

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#43

Post by GolDDranks »

tialaramex wrote: post #34
avgcorrection wrote: post #7

Gankra is the most entertaining Rust author (Rust programmer who writes about Rust). Easily.

Mmm. I think @m_ou_se is probably the most entertaining at least if we consider that both Saturday Night Live and Nightmare On Elm Street is entertainment. For example, Rust deliberately doesn't have the tertiary operator, and random other types don't get silently coerced as booleans - so you can't write a = x ? 1 : -1; however you can write a = if x != 0 { 1 } else { -1 }; with the same effect. But Mara isn't satisf…

That's a hilarious code crime! I checked it and it turns out that this works for 64-bit integers too. It's 2^128 - 1 that is the first number that requires five calls to count_ones to work!

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#44

Post by nyanpasu64 »

bluejekyll wrote: post #39
mbrodersen wrote: post #38

I wonder how much of the benefits comes from the rewrite itself and not Rust. I have taken really bad hard to maintain very large code bases written in C++ and step-by-step refactored it into bug free maintainable code. In my experience bad code written in any language is hard to maintain. And good code written in any language is easy to maintain. I have worked with C code that was a joy to maintain and C code that w…

There are entire classes of bugs that cannot happen in (safe) Rust that can still happen in a “bug free” C++ code based. You’re correct that Rust isn’t a panacea, but it does eliminate certain concerns that C++ just can not remove from thought while developing with it. The great thing about Rust is that it reduces the knowledge and skill a developer needs in order to write a stable and (usually) performant program. T…

Unsafe Rust is inevitable to write in any real-world program that needs {O(log n) insertion-ordered collections instead of key-ordered like BTreeMap, intrusive collections, custom lock-free data structures, or non-tree-shaped object graphs where you cannot spare the performance, static analysis, and ergonomic penalty of RefCell and Cell doesn't work out}, and working with aliasing pointers is so difficult (a representative example is https://github.com/Storyyeller/stable_deref_trait/issues/15) that I'd rather write C++ than unsafe Rust.

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#45

Post by bluejekyll »

nyanpasu64 wrote: post #44
bluejekyll wrote: post #39

Earlier quoted context omitted.

There are entire classes of bugs that cannot happen in (safe) Rust that can still happen in a “bug free” C++ code based. You’re correct that Rust isn’t a panacea, but it does eliminate certain concerns that C++ just can not remove from thought while developing with it. The great thing about Rust is that it reduces the knowledge and skill a developer needs in order to write a stable and (usually) performant program. T…

Unsafe Rust is inevitable to write in any real-world program that needs {O(log n) insertion-ordered collections instead of key-ordered like BTreeMap, intrusive collections, custom lock-free data structures, or non-tree-shaped object graphs where you cannot spare the performance, static analysis, and ergonomic penalty of RefCell and Cell doesn't work out}, and working with aliasing pointers is so difficult (a represen…

You’re mixing up two different categories of development. There are plenty of libraries that provide safe BtreeMaps and lock-free data structures. These can isolate all unsafe code in their own crate and only expose safe APIs.

Programs on the other hand can be written in entirely safe Rust, and the vast majority of Rust developers never need to use unsafe Rust to do this.

In Rust, we try to isolate unsafe usage and test it excessively. In C++ you have no such option.

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#47

Post by blablableu »

bluejekyll wrote: post #39
mbrodersen wrote: post #38

I wonder how much of the benefits comes from the rewrite itself and not Rust. I have taken really bad hard to maintain very large code bases written in C++ and step-by-step refactored it into bug free maintainable code. In my experience bad code written in any language is hard to maintain. And good code written in any language is easy to maintain. I have worked with C code that was a joy to maintain and C code that w…

There are entire classes of bugs that cannot happen in (safe) Rust that can still happen in a “bug free” C++ code based. You’re correct that Rust isn’t a panacea, but it does eliminate certain concerns that C++ just can not remove from thought while developing with it. The great thing about Rust is that it reduces the knowledge and skill a developer needs in order to write a stable and (usually) performant program. T…

There are entire classes of bugs that cannot happen in (safe) Java/Erlang/Scheme/etc. that can still happen in a "bug free" Rust code base.

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#48

Post by nyanpasu64 »

bluejekyll wrote: post #45
nyanpasu64 wrote: post #44

Earlier quoted context omitted.

Unsafe Rust is inevitable to write in any real-world program that needs {O(log n) insertion-ordered collections instead of key-ordered like BTreeMap, intrusive collections, custom lock-free data structures, or non-tree-shaped object graphs where you cannot spare the performance, static analysis, and ergonomic penalty of RefCell and Cell doesn't work out}, and working with aliasing pointers is so difficult (a represen…

You’re mixing up two different categories of development. There are plenty of libraries that provide safe BtreeMaps and lock-free data structures. These can isolate all unsafe code in their own crate and only expose safe APIs. Programs on the other hand can be written in entirely safe Rust, and the vast majority of Rust developers never need to use unsafe Rust to do this. In Rust, we try to isolate unsafe usage and t…

So far I have found no Rust insertion-ordered collections which supports removing items without scrambling items (necessary for editing a key-value INI file) with O(log n) reads/writes, though you can use a vector with O(n) accesses which takes O(n^2) to lookup every key, which is probably good enough in most cases.

And non-tree-shaped object graphs are not a library concern, but permeate entire applications; if you want to rewrite an app using shared mutability in Rust, you must either write code awkwardly with Cell/RefCell (and RefCell has runtime overhead), restructure the whole program in one Big Rewrite, or fallback to unsafe accesses (at this point, outside of multithreading C++ is a better Unsafe Rust than Unsafe Rust).

Please respond with a factual rebuttal before downvoting.

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#49

Post by paavohtl »

nyanpasu64 wrote: post #48
bluejekyll wrote: post #45

Earlier quoted context omitted.

You’re mixing up two different categories of development. There are plenty of libraries that provide safe BtreeMaps and lock-free data structures. These can isolate all unsafe code in their own crate and only expose safe APIs. Programs on the other hand can be written in entirely safe Rust, and the vast majority of Rust developers never need to use unsafe Rust to do this. In Rust, we try to isolate unsafe usage and t…

So far I have found no Rust insertion-ordered collections which supports removing items without scrambling items (necessary for editing a key-value INI file) with O(log n) reads/writes, though you can use a vector with O(n) accesses which takes O(n^2) to lookup every key, which is probably good enough in most cases. And non-tree-shaped object graphs are not a library concern, but permeate entire applications; if you…

It seems that indexmap would fit your bill:

Repo: https://github.com/bluss/indexmap

IndexMap type itself: https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap...

It has amortized O(1) reads and writes, and it supports removal without maintaining order in O(1), or while maintaining order in O(n).

Re: Everything Is Broken: Shipping Rust-Minidump at Mozilla

#50

Post by bpye »

structural wrote: post #8
secondcoming wrote: post #4

Maybe I'm missing something, but they ported from C++ (because 'C++ is bad donchaknow') to Rust and still ran into problems parsing crash dumps? If the dump is corrupt then just stop trying to parse/make sense of it; it's garbage.

This is the excessively fun part of dealing with crash dumps in general. Many of them are going to be 1% corrupt, 99% fine, and somewhere in them likely has vital information about what caused the corruption. So the entire reason for being for things like rust-minidump are to make enough sense out of files that are known to be corrupt garbage to be able to find bugs.

The worst bugs are often the ones that have trashed some of the stack or ended up with some rubbish register state too, and so being able to try and get some useful information out of a seemingless garbage dump is critical. I imagine a project like Firefox is also big enough to see bad things happening because of incorrect CPU behaviour and bit flips and such too...
Post reply on HN