Update memcall_windows.go

Open jgowdy-godaddy opened this issue 11 months ago • 2 comments

Normalize the behavior of unlocking a region that is not locked which causes an error on Windows and succeeds on POSIX operating systems. This avoids panics that happen on Windows that don't happen on POSIX operating systems:

panicked: could not free lock on 0x19e748b1000 [Err: The segment is already unlocked.]

Feb 17 '25 20:02 jgowdy-godaddy

Are you importing this library directly or via another package?

What situation leads to freeing a lock on an unlocked region of memory?

Mar 02 '25 09:03 awnumar

We are using memguard, not using memcall directly. Our usage of memguard on Windows causes this panic, whereas usage on macOS and Linux does not. There are differences in how Linux and Windows tracks locks on overlapping regions, and differences in how the calls respond to unlocking a region that is not locked. I wouldn't expect there's anything we could be doing through the memguard interface to trigger this issue specifically based on usage. In the end, the differences in locking and unlocking behavior make trying to track this down for the Windows use case seem quixotic. That's why I'm suggesting just normalizing the VirtualUnlock behavior to the munlock behavior as much as possible.

Mar 10 '25 14:03 jgowdy-godaddy