There is a bug and I found a possible culprit (worked on Win 10):

https://github.com/lapce/lapce/issues/9#issuecomment-9935004...

Trying to allocate memory the size of an underflowed uint64 does not seem safe. Is this possible in safe Rust code? Is there a Rust build flag that would catch this behavior?

> Is this possible in safe Rust code?

Yes.

> Is there a Rust build flag that would catch this behavior?

Runtime overflow checks (resulting in panics on over/underflow) are enabled by default in debug builds, but can also be enabled for release builds, or disabled for debug builds: https://doc.rust-lang.org/cargo/reference/profiles.html#over...

Additionally, you can use `Wrapping<T>` or `wrapping_sub` when wrapping is intentional, or `checked_sub` and explicit edge case handling when you want checks regardless of general build settings.

EDIT: that said, that's for integer overflow. Sibling comment references https://github.com/lapce/lapce/issues/9#issuecomment-9935004... which appears to:

1. Have a floating point div by zero.

2. Truncate when casting +inf floating point to integer.

Standard library & language checks won't catch either, although it'd be easy enough to roll your own checked math floating point type wrappers / conversion methods that would, or use an existing crate (e.g. using https://docs.rs/az/latest/az/fn.checked_cast.html to go from f64 -> usize instead of the `as` keyword would've caught #2. Since `as` is truncation-bait, some people prefer using the From/Into traits (infalliable, nontruncating) or TryFrom/TryInto traits (falliable, checked) as a matter of habit, avoiding the `as` keyword. However, neither of those traits cover f32 -> usize.

It's not underflowing int. Actually it's a divide by 0 bug, because font handling returns 0 sometimes. See my sibling comment.

It doesn’t violate memory safety, so it’s perfectly valid to do this in safe rust

Just need more RAM.