If a corrupt BSON document is encountered, the error messages generated are usually unhelpful. These messages are particularly unhelpful because an error parsing or constructing a BSON object often results in the destruction of the object before the exception is caught, nullifying any attempts to examine the memory in a core dump.

For example, if a BSONElement has an invalid type an error message like the following is printed:

Assertion: Location10320: BSONElement: bad type 119 src/mongo/bson/bsonelement.cpp 599

This is also unhelpful because the file and line number reported will always be the same for this error, regardless of the location in the code.

We should consider dumping the following information in the face of these types of errors:

• Print the starting address and raw memory of the corrupt BSON object
• Print a stack trace to locate the code that encountered the error