Windows fixes for zsock_resolve and ztimerset selftest #2325
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Especially in Windows (at least on builds using MSVC), `zsock_resolve` randomly (but quite often) segfaults if the passed pointer is actually pointing to a native `SOCKET` instead of zactor, zsock, or a ZMQ socket. This happens because `zmq_getsockopt` tries to check if, after casting, the pointer points to an object with specific tag (`check_tag()`). Unfortunately, reading this area of memory is often an access violation if the pointer actually pointed to a `SOCKET` (which is a smaller data type). It seems that checking if the pointer is to a native socket first before checking if it is a ZMQ socket fixes this, so these checks were reordered. Resolves zeromq#2300
On Windows, the `Sleep()` function resolution (which is used by `zclock_sleep()`) can typically be as bad as 16 ms. This caused the selftest to randomly fail because it waited exactly the remaining time to the timer expiration before asserting the result. Made this more reliable by adding some margin to the sleep.
|
Likely resolves #2298 as well. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #2300 describes a randomly occuring crash in zpoller. I investigated this and indeed I have only seen it happen on Windows, but the reason for it could easily cause it to happen on other platforms too.
When
zsock_resolve()tries to resolve the passed pointer type, it first checks first againstzactorandzsock, which work fine because the tag is the first variable in those structs and small enough. But that's not necessarily the case with ZMQ socket object. And when a nativeSOCKETis passed to resolve function, thezmq_getsockopt()tries to check the tag by accessing memory that is outside the actual variable that contained the native socket number, which in turn causes (very often) an access violation on Windows.The solution I came up with is to reorder the checks so that native socket is checked before the
zmq_getsockopt(), which seemed to work. Any ideas if this could break some edge case?The other commit is a small fix to
ztimersetselftest which also failed every now and then on Windows. This is due to WindowsSleep()having only a typical resolution of 16 ms, and the sleep in the test was very exact. I just gave it some margin to sleep long enough.