You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
when guards are dropped out of order the original function is never restored #6
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
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).
Activity
mehcode commentedon Nov 10, 2018
We should probably at least use a mutex keyed to the target function address.
kazcw commentedon Nov 10, 2018
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).
test case for out-of-order drop