when guards are dropped out of order the original function is never restored
Opened this issue · 2 comments
This is inherent to the API, as there's no reasonable interpretation of what version to "restore" in such a case; so it might just be one for the "no monkey business" section of the manual
We should probably at least use a mutex keyed to the target function address.
Stacked patches of the same function would trigger Mutex::lock's unspecified behavior, and dynamically-created mutexes wouldn't help the thread safety issues.
If there were a singleton Patcher object, the borrow checker could ensure stacked guards aren't dropped out of order. Sharing the Patcher between threads would require protecting it with a Mutex, which would eliminate some of the possible race conditions (the read/write one, and also the mprotect/write one, but not the write/execute one).