[SERVER-43055] Prevent an exception from being thrown when gdb prints a BSONObj with datetimes beyond datetime.MAXYEAR Created: 27/Aug/19  Updated: 29/Oct/23  Resolved: 14/Jul/20

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Richard Samuels (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by PYTHON-1824 Add ability to workaround Python's da... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: STM 2020-07-27
Participants:
Story Points: 2

 Description   

The BSON Python package can throw exceptions; the GDB pretty printer allows these exceptions to escape up into gdb/lldb, which can cause them to crash (I'm not sure why).

Here is an example where I managed to get gdb to print a python stack trace and not crash (this is difficult to achieve):

(gdb) p oplogBSON         
$13 = owned BSONObj 340 bytes @ 0x555556a614a8Traceback (most recent call last):
  File "buildscripts/gdb/mongo_printers.py", line 130, in children
    bsondoc = buf.decode(codec_options=options)
  File "/opt/mongodbtoolchain/revisions/e84eb3fd219668197589e62dba14b9914712642d/stow/python3-v3.FFC/lib/python3.7/site-packages/bson/__init__.py", line 1164, in decode
    return _bson_to_dict(self, codec_options)
bson.errors.InvalidBSON: year 292278994 is out of range



 Comments   
Comment by Githook User [ 03/Oct/20 ]

Author:

{'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}

Message: SERVER-50774 Update PyMongo requirement to 3.9.0+

The GDB and LLDB pretty-printers were updated to call bson.decode() in
SERVER-43055, and the bson.decode() convenience method was introduced in
PyMongo 3.9.0. However, we never updated the required PyMongo version in
our build requirements. This change updates the requirement so debugging
works properly with newer server versions.
Branch: master
https://github.com/mongodb/mongo/commit/ebcf26aa0080bdd63392e0406c9b9336de3c4582

Comment by Githook User [ 23/Jul/20 ]

Author:

{'name': 'Richard Samuels', 'email': 'richard.l.samuels@gmail.com', 'username': 'richardsamuels'}

Message: SERVER-43055 Prevent exceptions when lldb prints a BSONObj with datetimes beyond datetime.MAXYEAR
Branch: master
https://github.com/mongodb/mongo/commit/6e554668a820530cdf79360e4be1851e4cde2905

Comment by Githook User [ 14/Jul/20 ]

Author:

{'name': 'Richard Samuels', 'email': 'richard.samuels@mongodb.com', 'username': 'richardsamuels'}

Message: SERVER-43055 Prevent an exception when gdb prints a BSONObj with datetimes beyond datetime.MAXYEAR
Branch: master
https://github.com/mongodb/mongo/commit/eb6dc1da7ce35cf005b20c2933108341f7dee1a7

Comment by Eric Milkie [ 10/Jul/20 ]

Thank you very much for this improvement!

Comment by Eric Milkie [ 23/Jun/20 ]

I think the replicator you wrote is appropriate for this ticket. We shouldn't be allowing exceptions to leak up into gdb from the pretty printers, regardless of whether gdb crashes or not.

Comment by Richard Samuels (Inactive) [ 23/Jun/20 ]

milkie Would you happen to have a small replicator in C++ that I can work with? I came up with the following:

    auto t = Date_t::max();
    BSONObjBuilder bob;
    bob.appendDate("test", t);
    auto b = bob.obj();
    raise(SIGTRAP);

p b after the SIGTRAP yields a similar traceback, but doesn't crash gdb (as supplied with the v3 toolchain). I'm guessing this has gone away since this ticket was originally filed.

Comment by Brooke Miller [ 15/Jun/20 ]

robert.guo and I discussed this in Needs Triaging and this may be good for you to work on, richard.samuels. The next phase of the Undo Integration will require us to build the tooling to  use gdb differently due to Undo's data tracing capabilities. It will be good to gain familiarity with gdb's Python API, which is identical to undodb's.

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