[SERVER-19255] Listener::waitUntilListening may return before listening has started Created: 01/Jul/15 Updated: 19/Sep/15 Resolved: 02/Jul/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code, Networking |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.5, 3.1.6 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | Adam Midvidy |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Backport Completed: | |
| Sprint: | Platform 6 07/17/15 |
| Participants: |
| Description |
|
The waitUntilListening function uses a condition wait with a predicate based on the bool Listener::_ready. Unfortunately, this variable is not initialized in the constructor, meaning that its value is indeterminate. In the case where it is indeterminately a numeric value interpretable as 'false', callers to waitUntilListening will return immediately, before listening has actually started. Note that repl::isSelf depends on the proper functioning of waitUntilListening, since otherwise it may attempt to connect before the socket is listening, leading to a false negative. |
| Comments |
| Comment by Githook User [ 10/Jul/15 ] |
|
Author: {u'username': u'amidvidy', u'name': u'Adam Midvidy', u'email': u'amidvidy@gmail.com'}Message: |
| Comment by Andrew Morrow (Inactive) [ 10/Jul/15 ] |
|
Per discussion with Dan and Adam, approving for backport to 3.0 and 2.6. |
| Comment by Githook User [ 02/Jul/15 ] |
|
Author: {u'username': u'amidvidy', u'name': u'Adam Midvidy', u'email': u'amidvidy@gmail.com'}Message: |
| Comment by Andrew Morrow (Inactive) [ 02/Jul/15 ] |
|
I think use of uninitialized memory is the domain of MSAN, which unfortunately is not something we can use quite yet. It basically requires full instrumentation, including linked libraries like libc and libstdc++. See http://clang.llvm.org/docs/MemorySanitizer.html#handling-external-code |
| Comment by Eric Milkie [ 02/Jul/15 ] |
|
Should the ASAN builder detect this issue? I thought it checked for conditional-branch-based-on-uninitialized-memory. |