#Fixing UB in random crates

1 messages · Page 1 of 1 (latest)

manic tangle
#

is there a way to print under miri without synchronization (not println!)?

tough leaf
#

or a static mut [u8; N]

manic tangle
#

it's multi-threaded

#

I want to know the order.... okay static mut should work

tough leaf
#

do you need synchronization between the printlns then

#

hmmmm

manic tangle
#

miri is single threaded right

#

so static mut should work

tough leaf
#

it is, yeah

#

it does pre-empt threads occasionaly

manic tangle
#

yeah I'm trying to debug a data race

#

need to know more details and println! is changing things

haughty mica
#

It will encourage me to work on it

manic tangle
#

static mut does not work

#

miri is detecting a data race ferrisWeary

tough leaf
manic tangle
#

no I'm using it lol

#

okay this works:

const EMPTY: String = String::new();
static mut PRINT_I: AtomicUsize = AtomicUsize::new(0);
static mut PRINTS: [String; 100] = [EMPTY; 100];

pub fn println(x: String) {
    unsafe {
        let i = PRINT_I.fetch_add(1, Ordering::Relaxed);
        PRINTS[i] = x;
    }
}

pub fn flush() {
    unsafe {
        for x in PRINTS.iter() {
            println!("{}", x);
        }
    }
}
tough leaf
#

oh no

#

that works

manic tangle
#

yes

#

I mean, it's sound

#

actually, I need to call flush right before the data race happens ferrisThink

#

there's no way to tell miri to keep running after a race is there

#

wait, can I open stdout as a File ferrisThonk

#
pub fn println(x: String) {
    unsafe {
        let mut f = std::fs::File::from_raw_fd(1);
        f.write_all(x.as_bytes()).unwrap();
        std::mem::forget(f);
    }
}
#

it works

tender nimbus
tender nimbus
tough leaf
tender nimbus
tough leaf
#

which would oom so fast you wouldn't believe

proper belfry
#

cargo-nextest is something my instinctual reaction of “just contribute to cargo” has forbade me from trying so far

#

but maybe I should

tender nimbus
#

There are many big very hard challenges around interesting this into cargo, that's why it is its own thing

proper belfry
tender nimbus
#

I don't remember specifics

thorny venture
proper belfry
#

alright, I’ll stomach it :P

thorny venture
#

And I think it is intended to move fast for now rather than be stuck by cargo

#

Eg cargo has unstable apis for ages now, and I can't use them in CI properly. Nextest just worked to get my nice junit output

proper belfry
#

also conrad you may be interested in the discussion starting about here <#rust-discussions-3 message>

proper belfry
#

it seems like we need better processes for development of tools like Cargo so experimentation can usefully happen in-tree

thorny venture
#

I think nextest also doesn't guarantee that your tests will work. If you have some sync in your tests it might fail because nextest is more parallel by default. Our test suite at work required fixing to use nextest

#

In fact, I had to debug annoying parallel test failures today. -j 1 all tests passed. In parallel a whole module of tests failed :(

#

The solution ended up being making a separate database table for each test ferrisClueless

#

For complicated reasons that I can't really explain but it was my whole day debugging why sometimes the test passed and sometimes it failed

manic tangle
#

sounds fun

thorny venture
#

Essentially we run background workers that process jobs in batches, we made a change that intentionally failed the batch job (which gets picked up later), but since its synced in the DB, some other tests were processing it in a different test context, so the actual test didn't detect the work being done

#

So we isolated the DBs so only that one test could process the jobs it scheduled

haughty mica
#

The only difference is that nextest runs different test targets in parallel

#

If your tests can't tolerate running in parallel that's mad sketch

tough leaf
#

test runner that runs tests concurrently with themselves to try and find tests that can't handle that

#

as in, running the same test twice

#

in parallel :P

haughty mica
#

cargo test already runs tests within a target in parallel, in the same process, which is super surprising to some people

tough leaf
#

i suppose the solution nowadays is a static mutex of () for each Thing that can't handle being run in parallel

#

or better yet fix your tests so you operate on isolated things

haughty mica
#

I think nextest breaks the static mutex trick

#

You can't synchronize across test targets with it

west violet
#

Shmem locks

tender nimbus
haughty mica
#

And it's glorious

ebon orbit
#

Henlo

#

sighhh is miri not available on latest nightly again

haughty mica
#

Hm

#

I'll see what I can do

#

Oh, there's no new release

ebon orbit
#

oh lol

#

what was that link for component availability again?

haughty mica
#

Also I don't use that, just FYI

ebon orbit
haughty mica
ebon orbit
#

ah

#

help my rustup folder is 36 gigabytes

#

oo

#

ferris_says no longer has UB

haughty mica
#

It's also possible I just need to rerun it

ebon orbit
haughty mica
#

The latest smallvec release is not on the ub page

ebon orbit
#

oh

#

mbmb

ebon orbit
haughty mica
#

But it isn't there

#

Oh

#

Link rot

ebon orbit
haughty mica
#

Smh

#

Oh I know what's up

ebon orbit
#

i think i might be able to send a pr to update smallvec in rhai to prevent UB

haughty mica
#

The code that renders that page is broken, I broke it a few days ago

ebon orbit
#

groan tests in miri are so slow

tender nimbus
#

they are a lot faster than they once were

haughty mica
#

If your Miri is relatively recent

#

Sounds like gimbles has a bazillion toolchains

haughty mica
#

Ok site should be repaired now

ebon orbit
tender nimbus
#

@haughty mica a comment on the StackCache reads:

/// This maps items to locations in the borrow stack. Any use of this still needs to do a
/// probably-cold random access into the borrow stack to figure out what Permission an
/// SbTag grants. We could avoid this by also storing the Permission in the cache, but
/// most lookups into the cache are immediately followed by access of the full borrow stack anyway.

isn't this incorrect, now that Item is bit packed and therefore the whole item is stored in the stack?

haughty mica
#

Yes that is incorrect

#

The whole item is stored in the cache

tender nimbus
haughty mica
#

This is my second delegate notlikeblob

tender nimbus
haughty mica
#

At work we're trying to make a short list of things to tell people not to do here, as sort of like ground rules. The most-agreed-upon one is

Don't rubber-stamp a PR just because Ben approved it

#

Btw I am trying to review this but English is hard

haughty mica
#

The nextest maintainer is a machine

tough leaf
#

also
do you know anything about the -Zmiri-retag-fields flag

haughty mica
#

Yes

tender nimbus
tough leaf
#

should i be going and investigating the cases where the stdlib fails with it

#

or is that a known issue

haughty mica
#

Does it?

tough leaf
#

yes

tender nimbus
haughty mica
#

Please report them

tough leaf
haughty mica
#

I think I already ran the stdlib tests with it

tough leaf
#

yeah i'm using miri-test-libstd

#

i forget if core passes or if i just got bored

haughty mica
#

Oh fuck yeah

tough leaf
#

alloc is where i expect the more spicy stuff to be in any case

haughty mica
#

I'm so happpy

#

Let me see if I can repro this

tough leaf
#

command's at the top btw

#

exact test

haughty mica
#

Yeah

tough leaf
#

i'll let core tests run

#

see if anything fun is found there

#

either a failure or an OOM

#

take your pick

haughty mica
#

Awesome

#

You should report this

tough leaf
#

where do miri failures go, rust-lang/rust ?

haughty mica
#

I can't figure out how to prevent my vec-box branch from running into this so I though it was just my fault because I could have sworn the whole thing passed cleanly before

#

Yes probably

#

The flag works as intended I think

tough leaf
#

ralf Has Awakened (i got 2 notifs from him replying to things i'm in, trying to push them forward)

haughty mica
#

I can write this up and credit you if that's what you're asking

tough leaf
#

nah i'll do it

haughty mica
#

Now this is podracing

#

With my unix-exec branch, nextest now works perfectly with Miri

tough leaf
#

i didn't ping ralf because i didn't want to annoy him even though i don't think he'd mind because i just know he'll find it anyways

haughty mica
#

That would be omegaroll

#

Ah yes, you have passed this VecDeque to a function, IT IS NOW IMMUTABLE

#

Oh wait

#

No this is so confusing

#

We're trying to use the base tag for writes and we can't because we got a SRO retag from a function argument

tough leaf
#

aren't we passing ownership of the Drain

#

oh

#

hm
drain internally is using an Iter (immutable reference)

haughty mica
#

Oh

#

Yeah

#

Oofies

tough leaf
#

is that where the SRO comes from

#

i assume so

haughty mica
#

probably

#

field retagging is rough because the span is just like "this line" and it could have recursed through who knows how much type

tough leaf
haughty mica
#

l m a o

tough leaf
#

does

does using iter invalidate deque

haughty mica
#

There's no invalidation here

tough leaf
#

right

haughty mica
#

You just can't write through deque while iter exists, because normally you could invalidate iter but since it is a function argument, you cannot

#

I think this might be fixed by making the iterator wrap a raw slice

tough leaf
#

can you move the iteration logic all to a RawIter and then have the others just be thin wrappers over that

#

that turn a *mut T into whatever is valid for them

#

also iter::adapters::flatten::test_trusted_len_flatten still running

#

no sign of stopping

#

so i guess TODO: work out why that takes actually fucking hours to run under miri

#
let iter = [(), (), ()].iter().flat_map(|_| [(); 1000]);
assert_trusted_len(&iter);
assert_eq!(iter.size_hint(), (3000, Some(3000)));
#

ah

#

i guess that's probably it

haughty mica
#

Test passes now

#

Yeah that's it

#

I commented with my explanation

#

Someone will have fun patching this

tough leaf
#

Ohhh I think I get it. it's basically

pub fn foo(x: &u32, y: *mut u32) {
y.write(42);
}

where x and y alias?

#

and that's not okay because if you pass something as an argument it must hold until the return of the function?

haughty mica
#

Yes

tender nimbus
#

because we want funny llvm attributes ferrisWhen

neon tiger
#

we do a little optimization

tender nimbus
neon tiger
#

that is pretty funny ngl

#

the mem::transmute paw curls a finger as it passes the size check

tender nimbus
#

hey fewwis can you eval ```rust
unsafe {
let mut vec = Vec::from_raw_parts(1 as *mut u8, 0, 10);
vec.push(1);
}

small apexBOT
#
timeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11:     7 Segmentation fault      timeout --signal=KILL ${timeout} "$@"
tender nimbus
#

holy shit that's a segfault in Vec::push, better open an issue

neon tiger
#

rustsec advisory incoming

#

all hands on deck, it's a 10

tender nimbus
neon tiger
#
// in std::mem
enum Vibe {
  Inty,
  Pointery,
  Uninity
}
tender nimbus
#
error[E0512]: cannot transmute between types of different vibes
 --> src/main.rs:3:5
  |
3 |     std::mem::transmute::<u64, &[u8; 8]>(0)
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
  |
  = note: source type: `u64` (inty vibes)
  = note: target type: `&[u8; 8]` (pointery vibes)

For more information about this error, try `rustc --explain E0512`.
#

this would be a great addition to our memory model, since it's very vibey already

tough leaf
#

wait could we panic on any transmute from an integer type to a non-ZST reference

#

transmutes don't bless the reference with provenance

#

(it's fine for a ZST tho)

#

and if we're saying it's dereferencable....

tender nimbus
tough leaf
#

this is about ptrtoint but it does say provenance is removed

tough leaf
neon tiger
#

how do we compile from_exposed_addr?

#

given recent events, the answer is probably "wrongly" ferrisWhen but how should we compile it?

tough leaf
#

llvm has inttoptr and ptrtoint instructions, doesn't it?

#

?llvmir

#![feature(strict_provenance)]

pub fn owo(x: usize) -> *const u8 {
  std::ptr::from_exposed_addr(x)
}

pub fn uwu(x: usize) -> *const u8 {
  unsafe { std::mem::transmute(x) }
}
small apexBOT
#
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i8* @_ZN7example3owo17h6e6f82da7fd68509E(i64 %x) unnamed_addr #0 {
  %0 = inttoptr i64 %x to i8*
  ret i8* %0
}

attributes #0 = { mustprogress nofree norecurse nosync nounwind nonlazybind readnone uwtable willreturn "probe-stack"="__rust_probestack" "target-cpu"="x86-64" }

!llvm.module.flags = !{!0, !1}

!0 = !{i32 7, !"PIC Level", i32 2}
!1 = !{i32 2, !"RtLibUseGOT", i32 1}
tough leaf
#

hmmmm

tough leaf
#

does a transmute do an inttoptr too?

tender nimbus
#

hey fewwis can you llvmir ```rust
pub fn uwu(x: usize) -> *const u8 {
unsafe { std::mem::transmute(x) }
}

small apexBOT
#
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i8* @_ZN7example3uwu17h0d2aef5dcb2270caE(i64 %x) unnamed_addr #0 {
  %0 = inttoptr i64 %x to i8*
  ret i8* %0
}

attributes #0 = { mustprogress nofree norecurse nosync nounwind nonlazybind readnone uwtable willreturn "probe-stack"="__rust_probestack" "target-cpu"="x86-64" }

!llvm.module.flags = !{!0, !1}

!0 = !{i32 7, !"PIC Level", i32 2}
!1 = !{i32 2, !"RtLibUseGOT", i32 1}
tender nimbus
#

yeah

tough leaf
#

it DOES

#

sneaky fuck

tough leaf
#

?llvmir

pub fn uwu(x: [usize;2]) -> [*const u8; 2] {
  unsafe { std::mem::transmute(x) }
}

pub fn owo(x: [usize;2]) -> [*const u8; 2] {
  x.map(|x| x as *const u8)
}
small apexBOT
#
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

%"unwind::libunwind::_Unwind_Exception" = type { i64, void (i32, %"unwind::libunwind::_Unwind_Exception"*)*, [6 x i64] }
%"unwind::libunwind::_Unwind_Context" = type { [0 x i8] }

define void @_ZN7example3uwu17h1bbbc5917c46399fE([2 x i8*]* noalias nocapture noundef writeonly sret([2 x i8*]) dereferenceable(16) %0, [2 x i64]* noalias nocapture noundef readonly dereferenceable(16) %x) unnamed_addr #0 {
  %1 = bitcast [2 x i64]* %x to i8*
  %2 = bitcast [2 x i8*]* %0 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* noundef nonnull align 8 dereferenceable(16) %2, i8* noundef nonnull align 8 dereferenceable(16) %1, i64 16, i1 false)
  ret void
}

define void @_ZN7example3owo17h3a66012a35f73094E([2 x i8*]* noalias nocapture noundef writeonly sret([2 x i8*]) dereferenceable(16) %0, [2 x i64]* noalias nocapture noundef readonly dereferenceable(16) %x) unnamed_addr #0 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* @rust_eh_personality {
  %1 = bitcast [2 x i64]* %x to <2 x i64>*
  %2 = load <2 x i64>, <2 x i64>* %1, align 8
  %3 = inttoptr <2 x i64> %2 to <2 x i8*>
  %4 = bitcast [2 x i8*]* %0 to <2 x i8*>*
  store <2 x i8*> %3, <2 x i8*>* %4, align 8, !alias.scope !2, !noalias !7
  ret void
}

declare void @llvm.memcpy.p0i8.p0i8.i64(i8* noalias nocapture writeonly, i8* noalias nocapture readonly, i64, i1 immarg) #1

declare noundef i32 @rust_eh_personality(i32, i32 noundef, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*) unnamed_addr #2

attributes #0 = { mustprogress nofree nosync nounwind nonlazybind uwtable willreturn "probe-stack"="__rust_probestack" "target-cpu"="x86-64" }
attributes #1 = { argmemonly mustprogress nofree nounwind willreturn }
attributes
```Output too large. Godbolt link: <https://godbolt.org/z/1sPb53fWM>
tough leaf
#

for being the exact same function as owo

tough leaf
#

they'll point to the same function

tender nimbus
#

deduplicated, yeah

tough leaf
#

now

neon tiger
#

so transmute already knows the types' vibes internally ferrisOwO

tough leaf
#

is this okay

#

does this inttoptr

#

or is it literally

#

if you are a single pointer

#

then we'll inttoptr you

#

otherwise

#

you're on your own

#

use as

neon tiger
#

what does bitcast do ferrisThonk

tough leaf
tender nimbus
#

HACK(eddyb) LLVM doesn't like bitcasts between pointers and non-pointers.
lol

neon tiger
#

yeah it looks like UB

#

to bitcast between ints and pointers

#

very cool hack thank you eddyb

tough leaf
#

so basically, uwu takes two arguments, both pointers
a pointer to the start array as a [2 x i64]*, and a pointer to the return place as a [2 x i8*]*
we cast both of those pointers to i8* so we can pass them to memcpy, then we do the memcpy
then we return

#

so yeah

#

provenance is not kept

neon tiger
#

I think this is related to the "LLVM IR can't implement memcpy" issue

#

to which the proposed solution are byte types

#

you could then emit bytecast for all transmutes and LLVM would do the right thing

tough leaf
#

well, not quite

#

if you want to turn a usize into a *const u8 in a way that recovers exposed provenance, you need to actively do an operation on that usize

#

you can't just cast it

#

ptr <-> int transmutes aren't UB

but integers don't hold provenance

neon tiger
tough leaf
#

does a bytecast do an implicit ptrtoint

neon tiger
#

the proposed semantics are that bytecast from int to ptr does ptrtoint

tough leaf
#

even for arrays

#

ah

#

isn't that kind of a footgun

neon tiger
#

it's basically a device to select the right cast for you

tough leaf
#
safety: U is not larger than T
unsafe fn transmute<T>(item: T) -> U {
  let mu = ManuallyDrop::new(item);
  let p = &mu as *const ManuallyDrop<T> as *const T as *const U;
  p.read_unaligned()
}
#

does this do a ptrtoint?

neon tiger
#

depends on how you lower it

tough leaf
#

where is the ptrtoint done though?

#

at the read_unaligned?

neon tiger
#

probably yeah

tender nimbus
#

i mean

tough leaf
#

but the read_unaligned read a pointer

#

not an int

#

it doesn't have the int

neon tiger
#

hmm?

#

oh, I see what you mean

tough leaf
#

does every read_unaligned have to magically

tender nimbus
#

you can transform this "addrof ptrcast read" into "a_real_transmute"
at which point there is only one place for it to happen

tough leaf
#

do a ptrtoint

#

just in case

neon tiger
#

you would not read int nor pointer

#

you'd read a b64

#

and bytecast it

tender nimbus
#

but yeah

tough leaf
#

so literally all memory access goes through bytes

neon tiger
#

yes

#

unlike C, where only memory accesses at character type go through bytes ferrisWhen

#

Rust has no strict aliasing after all

tough leaf
#

this doesn't seem sound in the general case
but i can't think of a counterexample

#

where it's literally impossible to confuse llvm into not inserting an inttoptr

#

even through, say, union reads

tough leaf
#

not in the "typed memory" sense

#

but a uninit byte is different from a raw byte is different from a pointer byte

tender nimbus
#

what are you talking about exacty 522?
AM semantics?
LLVM semantics?
rust to llvmir lowering?

tough leaf
#

the proposal is to make LLVM always detect any form of ptr to int transmutes

#

as i understand it

tender nimbus
#

at the AM level we have

enum Byte { Int(u8), Ptr(u8, Prov), Uninit }

the memory read_unaligned is reading from is of type Int
but we want a pointer, so we need to convert it into Ptr
converting - inttoptr

neon tiger
#

that's exactly what the byte types are for

tough leaf
#

what if i read 1 byte at a time

#

into some place

neon tiger
#

to reflect the possibility of having integer, pointer and/or padding bytes in the same type

#

or poison etc.

#

the upshoot is that pointer types need not be able to carry integers and vice-versa

tough leaf
#

so we're merging int and ptr bytes

#

ints can have provenance

neon tiger
#

no, we're introducing a third type in the middle

tough leaf
#

no, in the abstract machine

neon tiger
#

exactly so integers don't need to have provenance

tender nimbus
#

this llvm byte is not an integer

tough leaf
#

if i do a ptr to int transmute, honestly, i'd expect that to be a no-op

neon tiger
#

what is a "no-op"?

tough leaf
#

well

#

hm

#

i guess padding exists

tender nimbus
#

ptr2int transmute is ```rust
match byte {
Ptr(addr, _prov) => Int(addr),
_ => unreachable!(),
}

neon tiger
#

no actual physical bytes are being changed

#

so in that sense it is a no-op

#

a bunch of magic voodoo metastate is being changed

#

which we have decided we're fine with doing all over the place

#

I view the byte types as basically

#[non_exhaustive]
union Byte {
  Int,
  Pointer,
  Uninit,
  Poison,
  Undef,
  Padding,
  Null,
  Nil,
  NullButFromAnotherAddressSpace,
  MoreLLVMWaysToSpellUninit,
}
#

it's type erasure for typed memory

tender nimbus
#

😵‍💫

#

the playground doesn't display any message

#

it has the exact same rustc version than i have (rustc 1.62.1 (e092d0b6b 2022-07-16))

#

(it doesn't display any message on nightly either)

haughty mica
tender nimbus
#

oh, the offsets

#

yeah

#

but what is going on on the playground

haughty mica
#

Not sure, but there was recently a PR merged to add track_caller for Miri

#

Might be relevant?

tender nimbus
#

maybe, no idea

#

well

#

if it's stable "recently" then maybe

haughty mica
#

Not stable

#

Nightly, yesterday or the day before

tender nimbus
#

hmm, that's weird, because the playground is broken on stable as well

haughty mica
#

The good news is that nextest seems to be working
The bad news is that everything takes forever now

#

Some crates now take more than an hour

#

Maybe I should cap runtime per-crate as well as per-test

tender nimbus
west violet
haughty mica
#

Um what

haughty mica
west violet
#

Nextest has stuff for it

#

I assumed that's why you were using it for your miri thingy (does it have a better name?) so that you'd have machine-readable output

haughty mica
#

Lol no

#

I'm using nextest because it has per-test timeouts and process isolation for tests

west violet
#

I do realize that I didn't give any context for that lmao

#

I had an entire convo in my head and you got exactly none of it

haughty mica
#

All I care about is the exit code and parsing Miri diagnostics

#

Also I want the website to look just like your terminal would if you ran the tests yourself

tender nimbus
west violet
#

Everything was fine until the Miri nation attacked

haughty mica
#

Mirithon?

#

Because it runs for a long time

tender nimbus
#

that sounds fun

west violet
#

Milar (Mylar) because it:

  • Strengthens the ecosystem
  • Stretches programs/the machines its running on
  • Makes crates more reliable
haughty mica
#

Hmmmmmmmmmmmmmmmmm

neon tiger
#

UB-quitty

#
  • sees everything
  • helps you quit your UB habit
haughty mica
#

Oooooooooooo

wraith wind
tough leaf
#

see if that optimises to be good enough

wraith wind
#

swap_with_slice is just an assert + swap_nonoverlapping, and the slice splitting already guarentees they don't overlap and are of equal length

tender nimbus
#

a smaller fix would be to just do some pointer arithmetic on the first pointer to get the second pointer, but this works as well if it works

tough leaf
#

so yeah, swap_with_slice should be fine

#

and completely remove the unsafe

wraith wind
#

I did try pointer.add() but Miri still gave me the same error

tender nimbus
#

#[cfg_attr(miri, ignore = "Can't open files with isolation")]

MIRIFLAGS="-Zmiri-disable-isolation"

tough leaf
#

at least in the bit of the code anyways

tough leaf
#

depends how big the file is

wraith wind
tender nimbus
#

it's not quite "none"

#

but it shouldn't really matter here

wraith wind
# tough leaf depends how big the file is
> wc -c tests/res/*
1999999 tests/res/graph_1000n_1000e.txt
1999999 tests/res/graph_1000n_1000e_iso.txt
  19999 tests/res/graph_100n_100e.txt
  19999 tests/res/graph_100n_100e_iso.txt
4039996 total
wraith wind
tender nimbus
#

it depends a lot, but often it is "none"

#

Takes too long to run in Miri
could you maybe make the graph a little smaller in miri? would that be fast enough?

tender nimbus
#

or using #[cfg(miri)]

wraith wind
#

I wouldn't really know enough about the crate to change the test so that it still passes :/

tender nimbus
#

ferrisBut i am clueless about gaphs as well

wraith wind
#

I disabled that one because it was 16gb of RAM and 10 minutes in on my PC which I thought seemed a bit much

tender nimbus
#

that is a lot indeed

#

but yeah try to do it safely as 522 mentioned

#

btw

#

secret rust trick

#
- node_adjacencies[pos..pos + old_node_capacity]
+ node_adjacencies[pos..][..old_node_capacity]
wraith wind
#

Ooh

wraith wind
tender nimbus
pastel lily
#

yea sounds right

wraith wind
tender nimbus
#

yeah, that's also often the case

ebon orbit
tender nimbus
#

maybe

ebon orbit
#

?clippy

fn main() {
    let list = [1, 2, 3, 4];
    dbg!(&list[1..1 + 2]);
    dbg!(&list[1..][..2]);
}
small apexBOT
tough leaf
#

it would be a subjective lint

#

i don't think it should be on by default

#

since i think it is somewhat more confusing

tender nimbus
#

it's a little more confusing if you learn about it the first time

#

but it makes code a lot nicer once you know it

pastel lily
#

does it behave worse for bounds checks

#

well

#

bounds checks it's still just a min and a max

#

but does LLVM get the same range info

#

does it understand that that's start..len

tender nimbus
#

hey fewwis can you godbolt ```rust
pub fn uwu(a: &[u8], x: usize, y: usize) -> &[u8] {
&a[x..x + y]
}

pub fn owo(a: &[u8], x: usize, y: usize) -> &[u8] {
&a[x..][..y]
}

small apexBOT
#
example::uwu:
        push    rax
        mov     rax, rcx
        add     rax, rdx
        jb      .LBB0_3
        cmp     rax, rsi
        ja      .LBB0_4
        add     rdi, rdx
        mov     rax, rdi
        mov     rdx, rcx
        pop     rcx
        ret
.LBB0_3:
        lea     rcx, [rip + .L__unnamed_1]
        mov     rdi, rdx
        mov     rsi, rax
        mov     rdx, rcx
        call    qword ptr [rip + core::slice::index::slice_index_order_fail@GOTPCREL]
        ud2
.LBB0_4:
        lea     rdx, [rip + .L__unnamed_1]
        mov     rdi, rax
        call    qword ptr [rip + core::slice::index::slice_end_index_len_fail@GOTPCREL]
        ud2

example::owo:
        push    rax
        mov     rax, rsi
        sub     rsi, rdx
        jb      .LBB1_3
        cmp     rsi, rcx
        jb      .LBB1_4
        add     rdi, rdx
        mov     rax, rdi
        mov     rdx, rcx
        pop     rcx
        ret
.LBB1_3:
        lea     rcx, [rip + .L__unnamed_2]
        mov     rdi, rdx
        mov     rsi, rax
        mov     rdx, rcx
        call    qword ptr [rip + core::slice::index::slice_start_index_len_fail@GOTPCREL]
        ud2
```Output too large. Godbolt link: <https://godbolt.org/z/Ts8hf847c>
pastel lily
#

smh we should be able to have two uwus

tender nimbus
#

basically the same

tender nimbus
#

"RFC 1234 More Uwu"

pastel lily
#

this does look interesting

#

uwu has a check for the range being reversed and that the end is not OOB

tough leaf
#

x + y could overflow

#

so the range can indeed be reversed

pastel lily
#

yeah

tough leaf
#

ah, so this is actually faster

#

in the general case?

#

well

#

hm

pastel lily
#

oh it only needs to check the end if overflow doesn't happen I guess?

#

hm

#

what is it doing

tender nimbus
pastel lily
#

yeah

tough leaf
#

but like

pastel lily
#

uwu only does a range order (overflow) check and a end check

tough leaf
#

this seems actually non-optimal

pastel lily
#

owo does a start check for the first slice and an end check for the second

#

these are semantically different

#

that's really interesting though that it removes the start check entirely, because the end check also fails iff the range is in order

haughty mica
#

Sushi man needs a bonk

#

Did a UB

tough leaf
#

in regex?

#

or elsewhere

haughty mica
#

bstr

#

Pre release at least

#

I noticed it on the site

#

The one on the site is just UCG 133 but there's another use outside provenance

tender nimbus
tough leaf
#

mem::uninit FCW time

#

time to look up how the deprecated lint actually works

haughty mica
#

Yup!

tough leaf
#

since we also have to lint for let _ = std::mem::uninitialized so you can't just look for calls :(

#

ah well

#

now we just need to get sign-off on "uninit u8 is UB" that would be good i think

tender nimbus
tough leaf
#

hmmmm
or i could make deprecated take a "future_warning" parameter

#

which makes it a FCW

#

that's weird

#

i'll just make a new lint

haughty mica
#

Then justify the rule with the attribute

#

This is how we've done the rest of Rust semantics why stop now

tender nimbus
#

eh, why even need attributes or anything

#

just do it

#

like box

#

"safe code can't exercise this behaviour therefore it can't happen"

pastel lily
#

justify
bold assumption any Rust semantics are actually justified

delicate crown
tender nimbus
#

nothing obviously bad from skimming through it a little

delicate crown
#

Yeah, though they also use unsafe_op_in_unsafe. Sketchiest things to me are some weird wasm deref of int macros, but I don't know wasm well enough to say since it's a weird arch. Also this weird MU swap
https://github.com/roc-lang/roc/blob/641daab02c90b446d8dfad302a8c57c6dfab9f0d/crates/roc_std/src/lib.rs#L155
I recreated this in Miri and it didn't complain with the default settings. But also this function is sort of useless for non-safety reasons and I may make a PR removing it.

GitHub

Roc is a language for making delightful software. Contribute to roc-lang/roc development by creating an account on GitHub.

tender nimbus
#

couldn't they just make a ManuallyDrop self and then move out of the field ferrisballSweat

#

but also, mem::forget is an anti pattern

haughty mica
#

I'm sure they don't know that

tender nimbus
#

yeah

#

no one does :(

neon tiger
#

most people think it's an anti-pattern because it causes leaks but the cases where you don't leak are often even worse

tender nimbus
#

it's an anti-pattern because whenever you need to forget something it's usually because you don't want its drop code to run
and that's often because it has been put into some kind of invalid state, or it needs to not invalidate other things
if it's in an invalid state, moving it around is sketchy. and if it needs to now invalidate other things, moving it around is sketchy.

neon tiger
#

stable vec_into_raw_parts when ferrisSob

#

this is such an obvious API and the available alternatives are all terrible footguns

tender nimbus
tender nimbus
tender nimbus
#

don't die ferrisSob

tender nimbus
#

@haughty mica have you looked into hashbrown being broken under field retagging

tender nimbus
#

oh lol it's actually very trivial

#

mem::forget ferrisClueless

#

#[forbid(clippy::mem_forget)] when ferrisPlead

#

at least in unsafe code ferrisballSweat

tender nimbus
#

and now ci fails because of a rust windows bug ferrisClueless

haughty mica
#

Do you have a fix for it?

#

I think I looked at it but never attempted a fix

coral trout
#

Fixing sb errors: 15 minutes of staring at the error to understand SB, 1 minute of actual changes.

tender nimbus
tender nimbus
#

i've opened a pr already but pc-windows-gnu is currently broken prevent CI from passing

#

(the toolchain itself)

#

(chrisd opened up a fix pr on rust-lang/rust)

coral trout
#

I did spin::SpinMutex yesterday, one of the issues was that and was easy, the other was related to locks holding mut-refs instead of pointers

#

Which took me a bit to understand when exactly you got overlap, but once it clicked I now feel like I understand the SB model better than I did

tender nimbus
haughty mica
#

Ah very cool

coral trout
#

(Aside: I should run field-retags on my crates, I'm sus about at least one of them)

haughty mica
#

If they're published you can just look at them on the site

#

More reason to publish your stuff 😉

tender nimbus
#

how many crates do you run currently?

haughty mica
#

All of them

coral trout
#

How would I look for a specific crate? ctrl-f doesn't seem to do it :P

tender nimbus
#

neat

haughty mica
#

It is large

tender nimbus
#

you probably want to curl and grep it

#

the browser will be very sad

#

why do so many of those error ferrisSob

#

worse error rate than crater

grim copper
#

Is there an AnyMap alternative which is more sound that we could recommend?

tender nimbus
#

type map?

#

there's typemap_rev

thorny venture
thorny venture
#

I temporarily enabled my admin powers to deploy it without asking anyone

tender nimbus
thorny venture
#

It's fine. People trust me almost entirely with rust related things

#

I'm our Rust BDFL

tender nimbus
#

conrad learned a new word ferrisClueless

thorny venture
wraith wind
#

Having a look at https://miri.saethlin.dev/ub?crate=minimal-lexical&version=0.2.1 - a lot of the errors come from calling .as_(mut_)ptr() through Deref:

impl ops::Deref for StackVec {
    type Target = [bigint::Limb];
    #[inline]
    fn deref(&self) -> &[bigint::Limb] {
        // SAFETY: safe since `self.data[..self.len()]` must be initialized
        // and `self.len() <= self.capacity()`.
        unsafe {
            let ptr = self.data.as_ptr() as *const bigint::Limb;
            slice::from_raw_parts(ptr, self.len())
        }
    }
}

Almost all of the errors go away if I just add .as_ptr() and .as_mut_ptr() on the struct itself, but I'm not sure if that's a good fix, or if there's an issue with the deref implementation

#

self.data being a [MaybeUninit<u64>; 62]

haughty mica
#

No that sounds like the right thing to do to me

#

This is slice deref right?

#

That retags the whole slice which people often don't want

wraith wind
#

Yeah

tender nimbus
haughty mica
#

HUNH

#

Good question

tender nimbus
haughty mica
#

Holy shit that's a lot of those errors

#

Aaaaaaa

#

45 thousand

#

fuuck

tender nimbus
haughty mica
#

I should add a kind of dashboard page so that it's obvious when I screw up like this

haughty mica
#

Good news is the ETA is only 17 hours

#

Oh wait 19 hours

#

22 hours

#

Back to 15

#

I really played myself here

tender nimbus
#

what was the problem?

haughty mica
#

No idea.

#

Some mistake I made weeks ago

tender nimbus
haughty mica
#

At a guess, I was dorking with the commit that I build Miri from and got too creative

#

No need to load the big list of all crates, but also no ability to navigate

tender nimbus
haughty mica
#

"How has this crate been building for hours?"

╰ ➤ du -h target/debug/build/arpabet_cmudict-b9b99059bb1900c4/out/codegen.rs 
38M    target/debug/build/arpabet_cmudict-b9b99059bb1900c4/out/codegen.rs
tender nimbus
haughty mica
#

Just got a bunch of ICEs because rustdoc can't create a temp dir 😩

haughty mica
#

Okay I think the above situation is finally fixed

tender nimbus
#

thank you

grim copper
#

@haughty mica how often are the tests on the ub miri website updated?

haughty mica
#

When I damn well feel like it

#

If you have a request for something just let me know and I can probably do it quickly

tender nimbus
#

or when the run feels really bad and errors everything forcing you to rerun ferrisballSweat

haughty mica
#

Yeah that happens

#

Usually I don't let things get older than a few days, but that's in terms of published crates not Miri versions

#

Running newly published crates is a lot easier than re-running the universe

grim copper
haughty mica
grim copper
haughty mica
#

1.5.1 has been up on the site for a while

#

The site is rarely more than a few days behind

grim copper
haughty mica
#

This again

grim copper
tender nimbus
#

no hashbrown release yet ferrisPensive

haughty mica
#

Oh yeah no-sb/ub is very different

tender nimbus
haughty mica
#

the no-sb page is very out of date, I have like never updated it lol

#

I'll update it sooon

tender nimbus
#

it would be cool if there was some kind of "state" at least for the top crates like "fixed on master", "pr open" or whatever
but that would be effort to maintain ferrisballSweat

haughty mica
#

It would be a crazy amount of CPU work to do

#

I spend hardly any time maintaining the code for this thing, but like if you saw what this does to my power bill

grim copper
#

could that be done client-side?

haughty mica
#

Do what on client side?

grim copper
#

I guess effort though

#

looking up the state of the repo / crate

haughty mica
#

Seeing if it's fixed would involve running Miri

grim copper
#

not seeing if it's fixed, more just if it's out of date (there's a new version released)

haughty mica
#

Hm

#

That might be possible

tender nimbus
#

for example, what's the status of the top ub crates

grim copper
#

inb4 compile miri to wasm and run it client side

tender nimbus
#
help: <5091> was created by a SharedReadOnly retag at offsets [0x18..0x30]
  --> src/lib.rs:156:42
   |
51 |                 ptr::copy_nonoverlapping(&hole_guard.v[index + 1], &mut hole_guard.v[index], 1);
   |                                          ^^^^^^^^^^^^^^^^^^^^^^^^
help: <5091> was later invalidated at offsets [0x0..0x60] by a Unique retag
  --> src/lib.rs:156:73
   |
51 |                 ptr::copy_nonoverlapping(&hole_guard.v[index + 1], &mut hole_guard.v[index], 1);

lmao classic (scopeguard)

haughty mica
tender nimbus
#

it will only be a little bundle

#

just a few megabytes

haughty mica
#

The biggest obstacle is that Miri dynamically links to the rustc libraries

wraith wind
#

Exploit the users browser and upload + run miri natively

haughty mica
#

@grim copper updated now

grim copper
haughty mica
#

Still working through the rest of the crates

#

eta 10 hours, but arc-swap is done

grim copper
#

sweet, so csv looks like the next top contender

haughty mica
#

That one is already spoken for, sadly

tender nimbus
grim copper
#

ah

tender nimbus
#

just like hashbrown ferrisWhen

haughty mica
#

plotters though

#

That is big sus

tender nimbus
#

I can't find it, can you send a link?

tender nimbus
#

ah, the no-sb

haughty mica
#

Yeah we get timeout/OOM with SB on

#

I am working on the tag GC right now

tender nimbus
#

plotters ferrisballSweat

#

what ferrisballSweat

#

why is their rgb pixel doing unaligned reads

haughty mica
#

There's a

#[allow(clippy::many_single_char_names, clippy::cast_ptr_alignment)]

Above the function

tender nimbus
#

oh they also do unsound tuple transmutes

#

of course

#

this crate is pretty sus

#

overall

haughty mica
#

Well, that's why the site exists 🙂

#

Now we know 🙂

#

And maybe the author can too 🙂

tender nimbus
#

maybe someone should fix all their unsafe code ferrisClueless

grim copper
#

I'm more worried about the alloc-[no-]stdlib crates

#

looks like they're used in dropbox and they're effectively just casting uninit memory

#

and brotli ferrisballSweat

#

at least plotting is not usually connected to the internet

haughty mica
#

I think I fixed the alloc-no-stdlib crates? And they just didn't publish?

#

Or maybe not

grim copper
#

opened jan 30

haughty mica
#

What's this abut brotli?

#

Oh maybe I never fixed it

grim copper
haughty mica
#

Ah I see

#

Well from what I recall this is UB in the tests, not the actual code

#

Same as scopeguard

grim copper
#

yeah, but the test looks like its just using one of the allocators provided by the crate

#

allocate array -> write to some of it -> read from it -> UB

haughty mica
#

Yes?

#

So you're saying this has a soundness issue?

grim copper
#

seems like it?

#

looks like it can leak data from the stack

#

allocate array -> don't write to it -> read from it -> data leak

#

no sure why the other tests didn't fail though, so maybe there's some condition to it

#

I haven't looked at the details

#

oh wait the failing case is on the heap not the stack

#

even worse

#

eg. if you can read uninit heap memory, you could eg. read private keys out of the process that have been deallocated

haughty mica
#

If you feel strongly about this, talk to RustSec

#

The group is bigger and more active recently, I'm sure if you open an issue on rustsec/advisory-db at least pinkforest will engage with you

grim copper
#

I'll have to investigate it more thorougly, which I may be able to do a bit tomorrow

#

I'd like to at least have a somewhat working exploit POC before I go to rustsec

haughty mica
#

Well if it's an unsound library, exploits are not really a thing?

grim copper
#

???

#

what u mean?

#

also dropbox has a bug bounty, so if I can make something juicy I may be able to payout

haughty mica
#

A very unsound library like this may be used in a way which is completely correct

#

And in fact that tends to be the common case

grim copper
#

right yeah. An exploit would just involve using the library in a way that resembles a real-world scenario and leaking some simulated info

haughty mica
#

I don't think that would alter anyone's assessment of this issue

#

Everyone in rustsec will understand that this is use of uninitialized memory, which can be used to leak secrets

grim copper
#

yeah I suppose

#

ok, I might write it up on rustsec tomorrow

haughty mica
#

And it is unlikely that Dropbox will care, unless you can actually make one of their services leak a secret

tender nimbus
#

File a rust sec and get 10.0 critical because "we don't know if it's misused like this and have to assume the worst"

haughty mica
#

Okay no-sb/ub is up to date again with the top 10k crates

#

Wild I feel like there are at least 3 buffer overflows in here

tender nimbus
#

simd again?

haughty mica
#

No

#

At least one of them is a randomize-layout situation

tender nimbus
haughty mica
#

People do UB for strange reasons

#

I always run these tests with randomize-layout

#

And I'm looking for invalid pointer offset errors

#

Because any buffer overflow will probably be one of those before you get to the OOB access

tender nimbus
#

lol

west violet
haughty mica
#

Yeah randomize-layout turns up a fair bit of smelly code

west violet
#

It was all worth it

tough leaf
#

now make it randomize (T,)

#

(maybe don't)

haughty mica
#

Did the padding thing ever land? I don't think so right

tough leaf
tender nimbus
#

now make it randomize fat pointers (DO NOT)

west violet
#

It does, actually

#

I got stuck on some funky ci error at some point

#

I was actually just looking at it

tender nimbus
#

wait what

#

doesn't that break std ptr::metadata

west violet
#

No

tender nimbus
#

why

west violet
#

...because it doesn't?

tender nimbus
#

but I thought std does union transmutes of fat pointers

tough leaf
#

which uhhh

tender nimbus
#

also breaking fat pointers will break crates like dyn-clone

tough leaf
#

yeah i think fat pointer layout is something we just gotta specify

#

well

#

what is the current layout

tender nimbus
#

yes

#

OTOH

#

It doesn't really matter

#

one ptr metadata is out

tough leaf
#

?eval

let x: [usize; 2] = unsafe { std::mem::transmute(&[0] as &[i32]) };
x
small apexBOT
#
     Running `target/debug/playground`

[93972223787100, 1]
tender nimbus
#

I mean is de facto specified we won't change it and no one will

tough leaf
#

grrrr

#

yay

#

okay

#

it's (ptr, len)

tender nimbus
haughty mica
#

It matters for all the old code that won't be upgraded

tender nimbus
#

true

#

it will become less important but there's still no reason to change it

#

so Let's Specify It
(Someone should write an RFC but it will not be me because oh god it would be worse than offsetof)

haughty mica
#

Lol

#

I'm not sure it would be

#

At the very least, if the same person would appear on my RFC I won't be patient at all with them

tender nimbus
#

a lot of people have been told that unspecified layout of repr(Rust) is great (and it is great indeed!)
i would feel that many people would immediately be opposed to specify it - though if the RFC did a good job of explaining the reasons behind it it could work

west violet
#

Specifying all rust layouts would be an exceedingly bad idea

#

Specifying slices/str, no brainer

#

Trait objects, ehhhhhh

#

We still haven't figured out trait objects fully

tender nimbus
#

trait objects are the interesting thing that people actually rely on though

#

slice fat pointers don't really make sense, we have from_raw_parts/x as *const _, x.len()

#

i mean we could of course specify them to be a repr c tuple but i don't think that's worth actually spending effort on since i dont think people actually rely on that

tender nimbus
haughty mica
#

Oh look it's the same time as with C++ ABI

neon tiger
#

slice is same except vtable is len: usize

ruby jacinth
#

more like rust struct Ptr<M: Metadata> { data: *mut (), meta: M, }

#

if its a slice, that meta is a usize, if its a trait object a ptr to vtable, if it is a normal pointer it's zero sized

west violet
#

Oh lordy me

#

They alloc a pointer, throw it into a Box::from_raw() and then pop() drops a Box::from_raw() pointing into the original allocation

#

It also decrements the length after deallocating the element which seems uh… wrong

tender nimbus
#

decrementing the length afterwards is ferrisballSweat

west violet
#

There’s a Box<[T; N]> and it basically does drop(Box::from_raw(&boxed_array[n]))

tender nimbus
#

so it loses write provenance?

west violet
#

So you can’t deallocate a portion of an allocation

#

You also can’t write to said deallocated portion

tender nimbus
#

ohhhh... it deallocates a suballocation????

#

wtf

west violet
#

Ye

#

I have literally no idea how this worked well enough to pass

tender nimbus
#

1.7k stars ferrisConcern

#

also ironic that the module is called borrow_stack

west violet
#

It’s almost poetic

haughty mica
#

Where are the tests

#

L M A O they have the default test still in the file

#

Empty safety comments too thonk

#

Wait a fucking second

#

What does this even do

#

I feel like that totally-not-a-dealloc is trying to call the drop impl

#

All that code that uses this is commented-out thonk

tender nimbus
west violet
#

Yah, I’m not really even sure what this could even do

#

Popping doesn’t give you the value back

tough leaf
#

(having a look at this now)

#

nor is get...

#

is this all just dead code

#

yes

tender nimbus
#

@haughty mica lmao i love the favicon

haughty mica
#

Thanks

#

I need to change the title too

tender nimbus
#

cowwo would also be great

haughty mica
#

Doesn't read well

#

Already looks bad just in Discord

tender nimbus
#

yeah it's a little small

#

ferrisball is great

haughty mica
#

It is very funny to me how some C dependencies have built setups that do not handle cgroups correctly

#

Yes, I do in fact have 64 cores under there, but if you spawn 64 processes you are going to get them all scheduled onto one core and you're going to like it

tender nimbus
#

their build setup may be older than cgroups and they've never bothered to fix it ferrisClueless

neon tiger
#

blindly spawning nproc many threads is a time-honored tradition ferrisClueless

tender nimbus
#

wait does nproc not respect cgroups

#

Print the number of processing units available to the current process, which may be less than the number of online processors
ferrisThink

tender nimbus
#

why the fuck would a build script do that

#

(I should not be asking this question)

tough leaf
#

or they're not using nproc

#

and just fuckin guessing

#

based on... whatever

haughty mica
#

I could be writing down the crates that do this but eh

neon tiger
#

there's a million ways to do this wrong and ignore cgroups

#

parse /proc/cpuinfo or whatever

tender nimbus
#

just parse some text files ferrisUwU

neon tiger
#

linux moment

tender nimbus
#

average unix philosopher

tender nimbus
ruby jacinth
#

great, yet another lint to ignore ferrisHotTake

ruby jacinth
tender nimbus
#

no

#

it needs to return *const ()

haughty mica
#

English is not your first language right

#

I can't explain why but your tense choices here are odd

tender nimbus
tender nimbus
haughty mica
#

Since as_ptr took a &self, the pointer won't have write permissions

In English it is common to say

Since as_ptr takes a &self, the pointer won't have write permissions

tender nimbus
#

yeah that does sound weird

haughty mica
#

I guess the idea is that you haven't made the call yet, so it's not right to use the past tense

#

If you were interrupting execution in the middle of the call with an error, your tenses would be correct

tender nimbus
#

well, you have made the call when you're doing the cast
but I guess takes makes more sense

haughty mica
#

You wrote the call, but you're not executing it

tender nimbus
#

yeah

haughty mica
#

Why do people have crates which hork in crater and dump gigabytes of logs

#

WHY

#

I'm uploading ASan logs and it's going very slow because


└── 100.00% [10.28 GB] ── logs
   ├── 51.55% [5.3 GB] ── clacks_mtproto
   ├── 11.69% [1.2 GB] ── pleingres
   ├── 4.68% [480.47 MB] ── ap_kcp
   ├── 0.56% [57.76 MB] ── goose
   ├── 0.35% [35.84 MB] ── braque
   ├── 0.32% [32.97 MB] ── cifar_10_loader
   ├── 0.29% [30.09 MB] ── noise_search_deps_librocksdb-sys
   ├── 0.21% [21.38 MB] ── asserhttp
   ├── 0.14% [14.27 MB] ── injrs
   ├── 0.13% [13.17 MB] ── mqf
   └── 0.10% [10.7 MB] ── fil_builtin_actors_bundle
tender nimbus
haughty mica
#

At least I only need to upload this once because the crate is dead

tender nimbus
#

good.

haughty mica
#

It needs a LOT of TLC still

#

For example, filtering out all the false positives due to custom stack mapping

#

And the "requested allocation size" crashes

#

And I need backtraces and diagnosis for the SIGILL crashes

#

Bad diagnosis

#

Anyway, someone should probably report all these security vulnerabilities ferrisClueless

tender nimbus
haughty mica
#

If someone scrapes this with a bot and reports every crate that uses loom OMEGALULiguess

tender nimbus
#

time to open like 20 issues on loom ferrisClueless

haughty mica
tender nimbus
#

ah

#

i was testing it on master lol

haughty mica
#

What do you mean by that?

tender nimbus
#

i tested miri on their master branch

#

which passed

haughty mica
#

Oh jorge fixed it already

#

... maybe

#

Anyway, the site is still valuable as a "do not use" flag

#

If they publish the fix, I'll update the site

tough leaf
#

wait why are floats commented out

#

lol

haughty mica
#

lul

tender nimbus
#

it's unmaintained has a rustsec and no one uses it so i guess its fine

haughty mica
#

Oh I should add the init checks

#

Lot more crates about to apppear 💀

#

543 crates in the list now

#

Only 218 of those are uninit issues

#

Yeah I'm changing the URL

#

Hope nobody posted URLs anywhere yet ferrisClueless

tender nimbus
#

which ones?

tough leaf
#

also
maybe have the root page be a landing page

haughty mica
#

The asan ones

tough leaf
#

with some text about what the site is doing and what the links are

haughty mica
#

Yes

#

Yes yes yes

#

This has been on my mind for a while and I would welcome a PR or a writeup by someone else

#

I just haven't gotten to it

tough leaf
#

because / being "lol fuck your browser" is somewhat annoying

#

ye fair

haughty mica
#

Is it still "lol fuck your browser" though

tough leaf
#

haven't tried too recently

#

i'll try on mobile

#

surely it will perform well

haughty mica
#

Oh dear

#

I just tried it... no sign of loading

#

😩

tender nimbus
#

my browser (chrome) is feeling fucked

#

it's actually kinda usable though

#

just slow

haughty mica
#

Yeah you can thank Zurr for that

tender nimbus
#

after waiting a few seconds to load

haughty mica
#

Furiosly refreshing my URL waiting for AWS infrastructure to warm up

thorny venture
#

furiously refreshing my email waiting for AWS job offer to come through

haughty mica
#

Ah it turns out I messed up in multiple ways

#

Between my 0% CPU usage, open window, and lack of pants, it's getting kinda cold in here now ferrisHmm

thorny venture
#

Turn up that CPU. Also, "lack of pants" is a lot more concerning in British English

haughty mica
#

I'm quite aware of the different meaning in British English ferrisWink

tender nimbus
haughty mica
#

ok my feet are kinda yellow, definitely need to get dressed

tender nimbus
haughty mica
#

I'm remembering that my "simple static site" actually involves a buttload of different AWS stuff

tender nimbus
#

it's web scale

haughty mica
#

FINALLY

tender nimbus
haughty mica
#

I just stuck a few panics into parsing paths where some terminal escape programs are like "fuck it don't handle this" and holy shit the strange stuff that's in these logs I have

#

For example, why does this one build script print environment variables,
Except when there are spaces,
It replaces them with 0x1F, the Unit Separator

#

I'm learning about most of these by reading the alacritty source code, because it helpfully documents what these all are then fully ignores most of them

#

Swap foreground and background colors; inconsistent emulation
Sounds like I can ignore it then!

tender nimbus
thorny venture
#

oh fuck oh fuck oh fuck

#

I decided to run my tests through miri. Doing crypto algs through miri is so slow

#

And it's using a lot of memory ferrisBorgar

haughty mica
#

Very cool

#

If you're willing to share it I can add it to the benchmark suite if it is unique

thorny venture
#

It does 4000 iterations of pbkdf2 basically

#

So uhh, it makes sense that it's slow

haughty mica
#

Ehhhh

#

There's "Miri is slow" then there's all the issues I've been closing about how Miri is slow

thorny venture
#

I'll let it run to completion. in debug the test took 0.13s

#

well, it's at least 3 minutes

#

11 minutes and still going

#

miri sat at 8GB of memory ferrisWeary

haughty mica
#

Yes we need better self-profiling support for this

#

Can you drop the workload size here a whole bunch?

#

Oh count

thorny venture
#

sure

haughty mica
#

Let's try 64

#

The problem is that the Rust-level profiling support that exists doesn't work if you have to kill the interpreter

thorny venture
#

15seconds

haughty mica
#

typenum

thorny venture
#

lmao ikr

haughty mica
#

I don't know where the memory is going though

#

That's a good question

thorny venture
#

stream ciphers still can't be represented with const generics ferrisWeary so typenum is necessary

haughty mica
#

Do you have any static/once_cell stuff in here?

thorny venture
#

not afaik

haughty mica
#

I don't even see any big arrays

#

So this is very strange

#

At a guess you have the SRW pileup issue

thorny venture
#

It's <linear it seems. I upped the number to 256 and it went to 45s

haughty mica
#

That's to be expected nowadays 😉

#

Miri shouldn't be much worse than linear, the big nonlinearity issue was solved

thorny venture
#

I guess my 4096 case would take 12minutes, but I think memory was becoming an issue at that point

haughty mica
#

I'll look into this later. Probably need to hack up the interpreter to figure out what's going on

thorny venture
#

nice

haughty mica
#

At a guess, there is a huge borrow stack somewhere

#

The perf probably doesn't go to shit because the lookup cache saves you, but the GC can't fix the memory growth issue

thorny venture
#

Yeah I don't see how

    for _ in 1..rounds {
        let mut prfc = prf.clone();
        prfc.update(&salt);
        salt = prfc.finalize_fixed();

        xor(chunk, &salt);
    }

would cause issues ferrisSweat

haughty mica
#

You like most Rust programmers are probably not thinking about what your code looks like when compiled without any optimizations

#

In any case, this is a good benchmark because it looks like it stresses the retag_return_place code path a lot, which I know I made slower with the stack cache but I couldn't justify doing fiddly optimization of it then

tender nimbus
haughty mica
#

Well yeah

#

Partly because it used to be that the whole story was "borrow stacks are always huge"

tender nimbus
#

I would go with RustCore of the 3 just to keep the name close to Rust. But I'm infamously bad with names already so :P

@haughty mica "miri-tools" crying on the corner

haughty mica
#

Exactly

#

It's now comfortably more than just Miri too

#

I need to properly integrate the ASan option

tender nimbus
#

I just had an idea for a way to print clean borrow stacks in Miri (at least with isolation)

Have a flag that sets the "print-alloc-id" and then a function like fn miri_print_stacks() which prints the stacks for the configured alloc id

This would not have tags around for getting the alloc id

You'd have to get the alloc id from a previous run, either through the usual function or just by doing a little ub

haughty mica
#

You can already do this btw

#

miri_get_alloc_id just returns a u64, you can print it yourself

#

I dislike this general strategy because it doesn't work if you have nondeterministic behavior, but I agree it works most of the time

#

Also, thoughts on how the GC should interact with this?

#

Should we have another magic function to turn it off temporarily? Warn if it's on and you print stacks?

#

Or run the GC right before each print?

haughty mica
#

The page is still flipping huge. Might need to address that.

haughty mica
#

I'm now pulling --no-default-features and --features from [package.metadata.docs.rs]
I see there's also a thing for rustdoc-args which I am ignoring for now. Seems interesting though.

#

I also have an ANSI-to-HTML renderer which is good enough to handle cargo nextest run so that'll be up soon

#

The downside is that this has exploded runtime because I'm only enforcing a 1-minute per-test timeout

haughty mica
#

Any thoughts on what to do if a crate has both metadata.docs.rs and metadata.playground?

#

Do like a... union?

west violet
#

Maybe give playground precedence

haughty mica
#

L M A O idna has its own test harness

#

RIP

#

Your tests will just never run under Miri

#

Startup time is somewhere beyond 3 hours and 8 GB of memory

haughty mica
#

Maybe that's just the copium kicking in

grim copper
haughty mica
#

That code for whatever reason is hitting some code path that defeats the stack cache

#

I'm not certain but it may be a GC interaction

#

Maybe that's just my paranoia

grim copper
#

idk, but I'm gonna run it for a few hours to see.

#

I'm only 1 hour in

#

but my desktop is reasonably beefy

tender nimbus
haughty mica
#

Latest ETA update: 36 days

#

I should probably be more strategic than "rerun every version of every crate with nextest"

tender nimbus
tender nimbus
#

Neat

ruby jacinth
#

Yay, another lint to ignore everywhere ferrisHmm

wraith wind