[SERVER-11902] mongorestore may terminate on invalid bson Created: 29/Nov/13  Updated: 10/Dec/14  Resolved: 30/Nov/13

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 2.4.8
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: James Wahlin Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Participants:

 Description   

When reading a document with invalid bson, mongorestore with object check enabled will:

  1. Call BSONObj.valid() to confirm whether valid
  2. If not it will iterate over the BSONElements
  3. For each iterated element it will:
    • Call BSONElement.validate() and print an error message if not valid.
    • Print to standard error the field name & bson type
    • Print to standard error the BSONElement

The issue we run into is the printing of the BSONElement can itself trigger an assertion (due to the invalid bson) that will then throw an exception. The exception thrown is not caught and causes process termination. We should protect against this. If we do want to terminate on this error we should do so explicitly. The code in question is available here: https://github.com/mongodb/mongo/blob/r2.4.8/src/mongo/tools/tool.cpp#L511

BSONObj o( buf );
if ( _objcheck && ! o.valid() ) {
    cerr << "INVALID OBJECT - going try and pring out " << endl;
    cerr << "size: " << size << endl;
    BSONObjIterator i(o);
    while ( i.more() ) {
         BSONElement e = i.next();
         try {
                e.validate();
         }
         catch ( ... ) {
               cerr << "\t\t NEXT ONE IS INVALID" << endl;
         }
         cerr << "\t name : " << e.fieldName() << " " << e.type() << endl;
 
         // exception is thrown by this statement in the printing "e"
         cerr << "\t " << e << endl;
     }
}



 Comments   
Comment by Eliot Horowitz (Inactive) [ 30/Nov/13 ]

See SERVER-11890

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