Mutex stuck locking forever under weird conditions

[Jerald]

I have a very weird situation where compiling a library on the machine my program is running will cause the mutex to get stuck locking. But only when called from specific places. There are a lot of moving parts to my project, so I honestly doubt much can be fixed from it. All I know is that using the mutex from parking_lot causes it to get stuck locking, while using the std::sync mutex works fine.

Below I've included a detailed description of my situation. But as I said, I honestly don't expect anything helpful to come from this due to the complexity of the whole thing.

If there's any other information I can give to help with the issue, let me know.

---

My project is a discord bot using the Serenity crate. I'm implementing a fancy system to dynamically reload commands from a rust dylib, helped by the libloading crate. To keep things threadsafe, I have a mutex around the inner framework of the bot, which is modified whenever something is reloaded. I noticed I got segfaults and other weird problems all of a sudden and it was quite confusing. After some debugging, I found out that some calls to lock the inner framework never completed, leaving things in a weird broken state.

Specifically, if I'm recompiling the program and I issue a command that locks the inner framework, the locking process will get stuck. Notably, this seems to only happen when the lock request is coming from some of the dynamically loaded code, since the main core of the bot can still lock the framework no problem. Whether it's coincidental that it's the dynamically loaded code that is able to cause it problem is unknown. I've not been able to make a minimally reproducible version of the error outside of my specific situation. Though it is consistently reproducible within what I have.

I've tried using the fair unlocking, thinking there was locking contention, but that had no effect. Using try_lock_until failed after the timeout, proving to me that it's not in fact crashed the thread, just stuck locking forever. As I said, switching to the std::sync mutex is the only thing that seems to fix the problem.

Here's a link to the repo of my project: https://github.com/Jerald/fracking-toaster The code there's not entirely up to date, but the part that causes is the issue is still present.