-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 6.0.0
-
Component/s: None
-
Query Integration
-
Fully Compatible
-
ALL
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In v6.0, the code in MozJSImplScope::_checkErrorState tries to detect whether the current exception was triggered from C++ or JS by checking for the existence of private data. It does so by unconditionally trying to get the private data slot pointer from the exception object (see implementation).
This is incorrect, as GetPrivate() expects that the object actually contains private data, as indicated by its flags. This is typically checked by the MOZ_ASSERT in this method, which unfortunately was not caught in v6.0, as this assertion only runs when we build with DEBUG enabled (i.e
"spider-monkey-dbg"
variant in master). GetPrivate() returns the memory address beyond the fixed data slots as a pointer, and we incorrectly assume that a non-nullptr value would mean that we had private data.
The correct way to check for private data is JSClass::hasPrivate() .
This bug was detected in both https://jira.mongodb.org/browse/AF-1324 and https://jira.mongodb.org/browse/HELP-68442 .
In those cases, running a map reduce to an output collection, where the map-reduce javascript code triggered a javascript error and where the output collection already had a large number of documents led to a segmentation fault during the merge/reduce step with the output collection.
Reproducing the crash is tricky, and required modifying map/reduce implementation to increase the number of calls to reduce. For this reason, the change for this bug fix will not contain an accompanying test.
Instead, this bug and the linked tickets should serve as a justification for backporting the spider-monkey-dbg variant to v6.0. The spider-monkey-dbg variant enables the assertions which would guarantee the code is used as intended, and should be used as our test barrier for this scenario.