unwrap panics in handle_deadlock

[michaelsippel]

Sometimes (3 out of 20 times cargo test) it happens that requests.get(...).unwrap() in handle_deadlock panics:

test lock_manager::with_deadlock ... FAILED

failures:

---- lock_manager::with_deadlock stdout ----
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/lock_manager.rs:226:102
note: test did not panic as expected

failures:
    lock_manager::with_deadlock

[p-avital]

Oof, non-deterministic error then? That'll be fun. Thanks for bringing it up, I'll check it out tomorrow :)
Btw, you seem to have taken an interest in this crate, and so did someone else this week, so I'm a bit curious: how did you stumble upon it?

[michaelsippel]

how did you stumble upon it?

Searched for something like "rust deadlock debugging" and it showed up.

[p-avital]

Ok, looks like when I switched from a 3 node types (Lock -> Threads -> Guards) to 2 node types (Lock -> Threads), I broke a bit of the invariants my graph used to have. Looks like it sometimes detects a reentrance instead of a deadlock. Weird, but at least that's a lead.

[p-avital]

Oooh, got it, the test fails because it detects the cycle from the reentrance detection test. I should make sure locks are removed from the manager when they are dropped ^^"

[p-avital]

how did you stumble upon it?

Searched for something like "rust deadlock debugging" and it showed up.

Thanks for trying it out, hope it didn't disappoint too much x)

Should be better now, let me know if you find other bad stuff happening :)