Fixed it! Part of me thinks I should try to make a minimal reproducer, just because.. wow, that was a weird one.

OTOH I don't know if there's a lesson here other than "my code was stupid and ugly, and x86_64 & arm64 have slightly different memory ordering". I already know these things!

no harm done! was a fun adventure!

buffers just love overflowing so dang much

ah shit I forgot there's no money in fixing problems!!

YEEHAW MISSION ACCOMPLISHED, I'M TECHNICALLY ALMOST A RUST CONTRIBUTOR

TIME TO BECOME CRAB BABYYYYY 🦀🦀🦀

Aaaand fixing the suspicious code in Buffer::read_more() fixes the crash. Success!!

Here's the PR to get the fix upstream: github.com/rust-lang/ru...

Changed it to peek(5) after the read(4) - which should trigger a read_more() while there's still data in the buffer - and blammo:

---- library/std/src/io/buffered/bufreader.rs - io::buffered::bufreader::BufReader<R>::peek (line 117) stdout ----
Test executable failed (signal: 6 (SIGABRT)).

6. read_to_string(s) - reads everything left ("hello") into s. Reader is now at EOF.
7. peek(1) - calls read_more(), but reader is at EOF, so it returns 0 and returns an empty buffer.

So the test does call read_more().. but it never actually reads anything! So let's fix that!

What the doctest does:
1. Make a Reader (`bytes`) containing 9 bytes: "oh, hello"
2. Wrap it in a BufReader (`buf`) with a 6-byte capacity
3. peek(2) - this causes a buffer fill. buf contains "oh, he". 4. read 4 bytes: "oh, ". buf now contains "he".
5. peek(2) - just returns "he". (cont'd..)

Anyway! `/x.py test library/std` takes a while but all the tests pass. Great work Rust folks, high-fives all around, &c.

Now let's see if I can trigger the problem. Let's look at BufReader::peek() and its doctest: github.com/rust-lang/ru...

Have I mentioned that my internet connection is a point-to-point microwave wireless link that we share with our neighbor 'cuz our house doesn't have line-of-sight to the tower?

SORRY ABOUT YOUR NETFLIX STREAMING QUALITY BUT I GOTTA REINSTALL XCODE BECAUSE NOBODY KNOWS HOW TO FIX CONFIG FILES

apparently the only suggestion for this is.. delete & reinstall the xcode commandline utils?

sudo rm -rf $(xcode-select -p) && xcode-select --install

[redownloads 2GB of data I already had]

...aaaaand now it works! What a cool and efficient way to fix my tooling configuration!!

Okay fine whatever, setup complete, let's see if we can build the libraries! And.. uh.. hm.

fatal error: 'iostream' file not found

hoorayyyyyyy missing search paths, my favorite

So first I guess I'll clone the rust-lang/rust repo. Yeehaw, 670MG of data, let's go!

Next they suggest using their `x.py` tool to bootstrap the build environment.

Is this gonna download a buncha binary tarballs from rust-lang.org without checking sigs or certs? HELL YEAH, I LOVE SOFTWARE

First, the bug: I think there's a logic error in std::io::buffered::Buffer::read_more() that will make std::io::BufReader::peek() segfault if it has to refill the buffer.

I'm not using peek() - or nightly, for that matter - but I *did* steal Buffer::read_more() for my own thingy.