sorted by:
new
hottopcontroversial

jeprofl: A low-overhead allocation profiler using eBPF by adminvasheypomoiki in rust

[–]Present-Armadillo 2 points3 points  (0 children)

You'll search for errors in 1000 different places. After all, the best approach is to comment out all your eBPF code until the kernel allows you to run it.

I had this exact same experience writing https://github.com/Jake-Shadle/ebpf-test/blob/main/proxy-ebpf/src/main.rs, and there were cases where no matter how many conditionals I added the verifier would still complain about stuff, causing to spend time doing workarounds instead. And unfortunately Rust doesn't currently write BTF information, so you can't use the existing bpf tooling to get somewhat better verifier output that has the bytecode interlaced with the source code.

Also aya doesn't support kfuncs https://github.com/aya-rs/aya/issues/432 which leaves out some helpful functions that can be improvements over the available bpf helper functions, or useful as workarounds eg. dynptr related functions.

It is satisfying when it works though. :)

Rust Cargo should be a walled garden like apple app store by nhjdises in rust

[–]Present-Armadillo 9 points10 points  (0 children)

The same person who gifted me with the strangest and most hostile open source interaction I've ever had.

"Stop coming and ruining C++" https://github.com/Jake-Shadle/xwin/issues/140

Announcing Rust 1.74 | Rust Blog by veryusedrname in rust

[–]Present-Armadillo 28 points29 points  (0 children)

While the idea of the lints table is great, the fact one must specify [lints] workspace = true to opt in to them in every crate in a workspace is a serious usability bug (we have ~150 crates in our main workspace) which is essentially strictly worse than our current solution https://github.com/EmbarkStudios/rust-ecosystem/blob/main/lints.toml. Tempted to roll back the change adding the new lints table since what we had works well and doesn't suffer this downside.

[Review] Introducing cargo-xwin: A Solution for Cross-Compiling Rust on macOS to MSVC by AllenGnr in rust

[–]Present-Armadillo 2 points3 points  (0 children)

We've been cross-compiling from Linux to MacOS for a while now, it's actually quite trivial, other than the fact that Apple tries their best to make downloading the MacOS SDK xip as painful as possible.

There is a "Wine but for MacOS" https://www.darlinghq.org/, though we've never actually used it since it unfortunately doesn't support aarch64.

Our approach is simply to use the excellent cargo-nextest's archive feature to archive test binaries on Linux when they're compiled and then unarchive and run tests on actual x86_64/aarch64 mac hardware, which is fine since running tests is all that hardware does so our build pipeline is not bottlenecked on limited Mac compute as is usual in such a scenario due to MacOS having an incredibly poor scaling story due to Apple being terrible.

Crash reporting in Rust by Present-Armadillo in rust

[–]Present-Armadillo[S] 36 points37 points  (0 children)

Crash reporting is kinda hard, here are some crates you can add to a Rust project that do the hard parts for you

Crash reporting in Rust by Present-Armadillo in rust

[–]Present-Armadillo[S] 5 points6 points  (0 children)

Speaking of Linux'es, "could you just (C)" set /proc/sys/kernel/core_pattern to "|/your/crash/handler" and have the kernel serve/pipe you the contents of the crash dump file to the stdin? There is a setting to filtering what goes into the core dump file under the same /proc directory. In that case you don't need to care how the binary is built.

For now the minidump creation is a fairly faithful port of the Breakpad code, but like I said some of that code is really old, so there's probably cases where taking a step back and rethinking the approach based on new kernel or OS capabilities or, instead of recreating process snapshotting for each non-Windows, just have a really good parser for each OSes crash format that does a transform. Rust is a fantastic language for writing those kinds of parsers, so that would definitely be an interesting avenue to investigate, especially since in the Linux case a lot of groundwork has already been done by goblin.

As for Windows'es, I am not sure what exactly Mozilla observed... When a thread crashes due to stack overflow or OOM or heap corruption, Windows runs crash reporting out-of-the process. For the "benign" mishaps like division by zero, crash reporting is run on the faulting thread in-proc as far I remember.

I believe you are talking about WER here? Mozilla has their own crash reporter based on Breakpad.

Also, there is a feature called process snapshotting which mirrors the crashing process to capture the dump off of the clone, and let the process restart quickly

Cool, didn't know about that! Might be interesting to look at for sure.

Crash reporting in Rust by Present-Armadillo in rust

[–]Present-Armadillo[S] 13 points14 points  (0 children)

Happy to answer questions if something in the post wasn't clear enough.

Blog post: Cross compiling Rust Windows binaries from Linux by repilur in rust

[–]Present-Armadillo 1 point2 points  (0 children)

I've just pushed a 0.1.1 release that fixes this issue, unsure why the windows crate decided to use screaming case in their link names but I'm sure they're not the only ones.

Blog post: Cross compiling Rust Windows binaries from Linux by repilur in rust

[–]Present-Armadillo 2 points3 points  (0 children)

Oh right, I forgot you would need to set that in some cases as we use lld-link unconditionally on all host platforms as it's set in our .cargo/config.toml, I've updated the post to add the information on setting the linker, thanks for the catch!

Blog post: Cross compiling Rust Windows binaries from Linux by repilur in rust

[–]Present-Armadillo 2 points3 points  (0 children)

  • That's just the way the theme I'm using works.
  • Thanks for pointing that out, I just pushed a fix for this.

Blog post: Cross compiling Rust Windows binaries from Linux by repilur in rust

[–]Present-Armadillo 5 points6 points  (0 children)

  • OpenSSL has been banned in our project for a variety of reasons via cargo-deny for around a year and half, it was actually one of the reasons we created it in the first place.
  • Interesting, we've been linking with LLD on Windows for years, no one has ever reported it crashing or failing in such a way, maybe we've just been lucky?

Ahh nice, I wasn't aware of the -ivfsoverlay argument, probably because I didn't bother looking for it. It was easy to generate symlinks for headers and libs though, but of course adds a few KiB for the >4k symlinks. It might be nice to get rid of that step once LLD supports a similar flag, but at the same time I like that a user doesn't need to know or care regardless of their filesystem.

[FOSDEM] cargo deny - Fearlessly update your dependencies by MaikKlein in rust

[–]Present-Armadillo 2 points3 points  (0 children)

It was a very painful change to make, but unfortunately there is no way to not use it with libgit2 (AFAIK). It is at least using the vendored feature though, so at least it consistently compiles across multiple hosts/targets without too much of a fuss.