automaxprocs VS trophy-case

We use https://github.com/uber-go/automaxprocs after we joyfully discovered that Go assumed we had the entire cluster's cpu count on any particular pod. Made for some very strange performance characteristics in scheduling goroutines.

Follow notable issues on https://github.com/golang/go to understand such things like why https://github.com/uber-go/automaxprocs was created.

AFAIK, it hasn't changed, this exact situation with cgroups is still something I have to tell fellow developers about. Some of them have started using [automaxprocs] to automatically detect and set.

[automaxprocs]: https://github.com/uber-go/automaxprocs

You could check cargo-fuzz trophy case, which is a list of issues that have been found via fuzzing.

I've added it to the trophy case.

The same fuzzing techniques applied to Rust yielded a lot of bugs as well. But in Rust's case only 7 out of 340 fuzzer-discovered bugs, or 2%, were memory corruption issues. Naturally, all of the memory corruption bugs were in unsafe code.

If you have found any bugs with this tool, perhaps add them to the Rust fuzz trophy case?

Source: https://github.com/rust-fuzz/trophy-case (over 40 of those are just from me).

But to bring some data, check out the fuzz trophy case. It shows that failures in Rust are most often assertions/panics (equivalent to C++ exception) with memory corruption being relatively rare (it's not never—Rust isn't promising magic—but it's a significant change).

You need to read the list more carefully.

• The list is not for Rust itself, but every program every written in Rust. By itself it doesn't mean much, unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs. For some context, see how memory unsafety is rare compared to assertions and uncaught exceptions: https://github.com/rust-fuzz/trophy-case

• Many of the memory-unsafety issues are on the C FFI boundary, which is unsafe due to C lacking expressiveness about memory ownership of its APIs (i.e. it shows how dangerous is to program where you don't have the Rust borrow checker checking your code).

• Many bugs about missing Send/Sync or evil trait implementations are about type-system loopholes that prevented compiler from catching code that was already buggy. C doesn't have these guarantees in the first place, so lack of them is not a CVE for C, but just how C is designed.

Well, it's more than 15 years old, and the ratio of critical security bugs to normal bugs found by fuzzers is lower for rust, which i know is not a perfect metric but it's at least a decent indication that it is actually safer. Source: https://github.com/rust-fuzz/trophy-case and https://lcamtuf.coredump.cx/afl/#bugs . Plus, speaking as somebody who does programming as a hobby, it does have some nice features( lifetimes, the way references work and being more explicit about duplication of data, etc.) in terms of memory management that even if they don't 100% prevent critical bugs at least help. But idk, in the grand scheme of things rust is still a new language, so i get the concern.

Fuzzing is still very relevant in Rust. It tends to find panics rather than segfaults, but that's still bugs.

https://github.com/rust-fuzz/trophy-case

To add data on the Rust side:

https://github.com/rust-fuzz/trophy-case

there are a few Rust ASN implementations. They've been caught running out of memory and having arithmetic overflows, but no segfaults or use-after-frees. Rust doesn't prevent all problems, but things that slip through tend to be less severe.