[SERVER-27643] Stack locator can return invalid stack size when stack size ulimit is unlimited Created: 11/Jan/17 Updated: 16/Apr/18 Resolved: 02/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.15, 3.5.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jonathan Reams | Assignee: | Jonathan Reams |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Requested: |
v3.4
|
||||||||
| Sprint: | Platforms 2017-01-23, Platforms 2017-02-13 | ||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
|
The stack locator calls pthread_getattr_np and then pthread_attr_getstack to determine how big the stack is. With glibc, that means that if the stack ulimit is set to "unlimited" it will try to determine the size of the stack as though it were UINT64_MAX which can cause the stack size to be reported as a negative number. This can cause the javascript engine to set its internal stack limit to a negative number which will prevent the creation of any new javascript scopes - although this only applies to main(), all our other threads either have an implicit stack size of 2MB or an explicit stack size of 1MB depending on how they were created. |
| Comments |
| Comment by Githook User [ 16/Apr/18 ] |
|
Author: {'name': 'Jonathan Reams', 'email': 'jbreams@mongodb.com', 'username': 'jbreams'}Message: (cherry picked from commit 611b493648e64678fccac94373707e12e3904e91) |
| Comment by Githook User [ 02/Feb/17 ] |
|
Author: {u'username': u'jbreams', u'name': u'Jonathan Reams', u'email': u'jbreams@mongodb.com'}Message: |
| Comment by Jonathan Reams [ 01/Feb/17 ] |
|
The fix for this is actually much simpler than I first thought. We just need to make sure we're using the right types when using the stack locator. If we make sure it's size_t all the way through, the very very large stack size returned by the StackLocator seems benign. There's a new code review to fix our use of the stacklocator in our javascript integration - which is where this bug first popped up. |