Weird UB when using sprs in nightly release mode

[Specy]

Is there anything I need to know about using the safe Api to prevent unsoundness?

I had to fork an unmaintained library whose only dependency is sprs, it does not use any unsafe but I'm experiencing really weird bugs that don't make any sense, and that seem to be UB. They happen only in opt-mode >= 1 and miri doesn't seem to catch anything

[mulimoen]

If it is just sprs and not the bindings then unsafe is only used for upholding the guarantee of sorted indices. This is just a correctness and performance thing, and not unsoundness

[Specy]

Unsoundness is the first thing that came to mind because of this:

20241029-2125-25.0816714.mp4

Where adding a print statement makes the code not panic on a guaranteed unwrap

Where the function returns None even though the branch of the None isn't hit (you can't see that on this video, it shows something else), and only returns None if compiled with opt-mode >= 1 (there is no race conditions, multi thread or IO that could cause this as simply a performance issue)

I'll investigate more today, just wanted to make sure that the bug wasn't coming from incorrect usage of sprs

[mulimoen]

That sure looks like undef behaviour. If the source is available then I'd be happy to take a look at it this afternoon

[Specy]

I made a minimal example here: https://github.com/Specy/microlp/tree/panic-bug, i've narrowed down the bug a bit, it only happens in release mode in nightly, running it on stable seems to work.

To reproduce the bug just run cargo run it should run with no errors, then run cargo run --release (in nightly!) and there should be a panic

I've used a debugger and found an illegal memory read in the unwrap

I've used nightly 1.83.0 and 1.84.0, bug happens in both, on stable and nightly 1.82.0 it doesn't happen

I had forked an unmaintained lib that uses this crate, i updated all deps to latest but this bug was happening also for sprs 0.9.2

[mulimoen]

It is not clear it is a bug in sprs, try the following:

order_simple(4, |c| {
        match c {
            0 => &[0, 1, 2, 3],
            1 => &[2],
            2 => &[0, 1],
            3 => &[1, 2, 3],
            _ => unreachable!(),
        }
    });

[Specy]

It is not clear it is a bug in sprs, try the following:

order_simple(4, |c| {
        match c {
            0 => &[0, 1, 2, 3],
            1 => &[2],
            2 => &[0, 1],
            3 => &[1, 2, 3],
            _ => unreachable!(),
        }
    });

Just tried that, the error still happens, i've filed a bug on the rust repo, just removed the sprs dependency, should i close this issue?

[mulimoen]

Yes, lets close this

[Specy]

Thanks for helping narrow down the bug!