[SERVER-30688] Using multiple changeStream cursors causes a segfault Created: 16/Aug/17  Updated: 30/Oct/23  Resolved: 17/Aug/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.5.11
Fix Version/s: 3.5.12

Type: Bug Priority: Major - P3
Reporter: Ross Lawley Assignee: Matthew Russotto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-30752 Invariant failure isCapped Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Open the shell and call next() on two changeStream cursors. Code example in the description.

Sprint: Repl 2017-08-21
Participants:

 Description   

When running on 3.5.11 or nightly the following code run in the shell causes the primary node to segfault.

use testChangeStreams;
db.dropDatabase();
 
// Example 1
print("1. First cursor value: ");
db.changes.insertOne({test: "a"});
var cursor1 = db.changes.aggregate([ { $changeStream: { fullDocument: "none"} } ]);
 
var next = null;
if (cursor1.hasNext()) {
    next = cursor1.next();
}
printjson(next);
 
// Example 2
print("2. Lookup enabled: ");
var cursor2 = db.changes.aggregate([{$changeStream: {fullDocument: "lookup"} }]);
 
while (cursor2.hasNext()) {
    next = cursor2.next();
}
db.changes.updateOne({test: "a"}, {$set: {test: "b"}});
next = cursor2.next();  // Segfaults
printjson(next);

(If testing on 3.5.11 change the aggregation to be $changeNotification).



 Comments   
Comment by Githook User [ 17/Aug/17 ]

Author:

{'username': 'mtrussotto', 'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto'}

Message: SERVER-30688 Make PlanExecutor wait for awaitData only when it has an awaitData CanonicalQuery
Branch: master
https://github.com/mongodb/mongo/commit/07197eb1c413b3ed94ce5633036ee0d64853cf36

Comment by Matthew Russotto [ 16/Aug/17 ]

This is caused by doing an awaitData query on the auxiliary (fullDocument) lookup.

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