[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:
Backports
Depends
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.4
Sprint: Platforms 2017-01-23, Platforms 2017-02-13
Participants:
Case:

 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: SERVER-27643 Use correct types when setting javascript stack limit

(cherry picked from commit 611b493648e64678fccac94373707e12e3904e91)
Branch: v3.4
https://github.com/mongodb/mongo/commit/90ef0561dd788959e246321112942e78282fd87d

Comment by Githook User [ 02/Feb/17 ]

Author:

{u'username': u'jbreams', u'name': u'Jonathan Reams', u'email': u'jbreams@mongodb.com'}

Message: SERVER-27643 Use correct types when setting javascript stack limit
Branch: master
https://github.com/mongodb/mongo/commit/611b493648e64678fccac94373707e12e3904e91

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.

Generated at Thu Feb 08 04:15:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.