[SERVER-57376] CollectionImpl and IndexCatalogImpl stats are uninitialized and can be written to the logs Created: 02/Jun/21  Updated: 29/Oct/23  Resolved: 13/Oct/21

Status: Closed
Project: Core Server
Component/s: Query Execution
Affects Version/s: None
Fix Version/s: 5.2.0, 5.0.4, 5.1.0-rc2

Type: Bug Priority: Major - P3
Reporter: Eric Cox (Inactive) Assignee: Haley Connelly
Resolution: Fixed Votes: 0
Labels: qexec-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.1, v5.0, v4.9, v4.4, v4.2
Sprint: Execution Team 2021-09-06, Execution Team 2021-09-20, Execution Team 2021-10-18
Participants:

 Description   

I found that there are a few int64s that are uninitialized and can possibly be written to the logs. This will show very large numbers of keysInserted for update operations when only a single document is updated in the logs and can be confusing to users leading them to believe that a replaceOne() on a single document leads to billions of updates.

Examples:

https://github.com/mongodb/mongo/blob/f1090ddbcc24bf61bdadc937c8bdd483878b49cf/src/mongo/db/catalog/collection_impl.cpp#L1207 

https://github.com/mongodb/mongo/blob/f1090ddbcc24bf61bdadc937c8bdd483878b49cf/src/mongo/db/catalog/collection_impl.cpp#L838 

https://github.com/mongodb/mongo/blob/f1090ddbcc24bf61bdadc937c8bdd483878b49cf/src/mongo/db/catalog/index_catalog_impl.cpp#L1348 

to name a few. This specific scenario might be hard to reproduce since the bug in reporting happened while 83 write conflicts occurred.

The relevant query is:

> db.c.drop()
> db.c.insert([{x: 1, y: 1}, {x: 2, y: 2}])
> db.c.replaceOne({x: 999, y: 999}, {x: 999, y: 999}, {upsert:true})

The goal of this ticket is to write a test to reproduce this scenario, initialize the vars that account for the keysInserted and show that we no longer report uninitialized data.



 Comments   
Comment by Githook User [ 25/Oct/21 ]

Author:

{'name': 'Haley Connelly', 'email': 'haley.connelly@mongodb.com', 'username': 'haleyConnelly'}

Message: SERVER-57376 Ensure CollectionImpl and IndexCatalogImpl stats are initialized

(cherry picked from commit ae87bea78ec2ea001185677ecce3c8a930f86555)
Branch: v5.0
https://github.com/mongodb/mongo/commit/4267f842e1d8fa10a92e2f339768b712f93cf4ba

Comment by Githook User [ 21/Oct/21 ]

Author:

{'name': 'Haley Connelly', 'email': 'haley.connelly@mongodb.com', 'username': 'haleyConnelly'}

Message: SERVER-57376 Ensure CollectionImpl and IndexCatalogImpl stats are initialized

(cherry-picked from commit ae87bea78ec2ea001185677ecce3c8a930f86555)
Branch: v5.1
https://github.com/mongodb/mongo/commit/a640356470c77683aa2f5262285d394ae18c8250

Comment by Githook User [ 13/Oct/21 ]

Author:

{'name': 'Haley Connelly', 'email': 'haley.connelly@mongodb.com', 'username': 'haleyConnelly'}

Message: SERVER-57376 Ensure CollectionImpl and IndexCatalogImpl stats are initialized
Branch: master
https://github.com/mongodb/mongo/commit/ae87bea78ec2ea001185677ecce3c8a930f86555

Comment by Haley Connelly [ 13/Oct/21 ]

We decided to just go ahead an initialize these to 0 and bypass spending time to reproduce in a test. I went through each of the files, looked at every instance of 'int64_t' to see if it was a declaration of a variable without initialization to 0.

Comment by Ethan Zhang (Inactive) [ 08/Jun/21 ]

eric.cox Is this in the storage execution code? If so, we might want to reassign?

Comment by Ethan Zhang (Inactive) [ 07/Jun/21 ]

This needs to be backported to 4.2.

Generated at Thu Feb 08 05:41:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.