Using this project as a faster miri?

[hkalbasi]

Hi! I see the GIF in your readme, then though that this project has potential of detecting memory bugs and more in the unsafe code, and I guess it is multiple orders of magnitude faster than miri. Have you considered this? What UBs are detected by this project and what are not? Even if detecting all UB is not feasible, it can be still useful. It can also have a opt-in mode that detect more UB at cost of some performance, I guess.

[IntegralPilot]

Hi! Someone actually asked me this the other day on Reddit too, I think it is a very exciting possibility. It would definitely be a lot faster, due to JIT. To quote what I said then:

The UB detection is currently a convenient side effect of all the bookkeeping we need to do in order to simulate raw pointer arithmetic on the JVM, so I don't currently guarantee anything to be caught yet, but in my experience most UB relating to misuse of pointers in some way will get caught. I plan to develop it into a dedicated feature soon and then will probably put some guarantees and clearer scope of what is and isn't possible to be caught (as I'm still experimenting with that now). I do think it does have potential as a Miri-lite (especially with the JVM's JIT), and that use case could be quite helpful.

I've been trying out making this a more explicit feature locally. I'd love to hear your (or anyone else who see this) thoughts, what kinds of UB do you think it would be most valuable to people to be catching?

[Mukad3]

Hi! I see the GIF in your readme, then though that this project has potential of detecting memory bugs and more in t

MIRI uses the stacked borrows model for correctness, and can optionally use the newer tree-borrows model. It's important to mention though that these are NOT normative specs for rustc, whose behaviour diverges from both of these specifications in a lot of places. Here's an example of a pretty famous divergence between the MIRI spec and the actual LLVM IR lowering:

https://rust-lang.github.io/rfcs/3467-unsafe-pinned.html

So I suppose whatever you end up doing along this path, make sure you reference this (incomplete) list:

https://doc.rust-lang.org/reference/behavior-considered-undefined.html

Just note that MIRI's stacked/tree borrows are not considered to be a normative specification for rust (yet), and the actual UB model is incomplete (mostly because rust hasn't quite figured out what it considers to be defined behaviour either).

[hkalbasi]

what kinds of UB do you think it would be most valuable to people to be catching

I would say all UBs are valuable, and the ones that tend to get miscompiled by llvm / has undesirable effects directly. So I would prioritize UBs as below:

1. Buffer overflow
2. Temporal memory issues (Use after free and double free)
3. Data race and thread safety bugs
4. Explicit unreachable_unchecked and library UBs
5. Aliasing UBs
6. Writing on read only memory
7. Unaligned pointer dereference

Also, another area of improvement on miri other than speed is the ability to calling native C code. I'm not sure if it is supported, but it would really help unsafe ffi codes.