[SERVER-27549] Log a message in MongoRunner.stopMongod() when allowedExitCodes is used to test intentional abort Created: 30/Dec/16  Updated: 22/Mar/18  Resolved: 30/May/17

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 3.4.1
Fix Version/s: 3.5.9

Type: Improvement Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Robert Guo (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-31013 Make serverExitCodeMap useful to dete... Closed
Backwards Compatibility: Fully Compatible
Sprint: TIG 2017-04-17, TIG 2017-05-08, TIG 2017-05-29, TIG 2017-06-19
Participants:
Linked BF Score: 0

 Description   

Some tests intentionally cause the server to abort (e.g. fatal assertion). When quickly scanning the log output for a reason as to why the test failed, Server team engineers are misled by backtraces appearing in the output. We should write a message in MongoRunner.stopMongod() when the allowedExitCodes option is being used to test for an intentional abort.

Original description

Some tests intentionally cause the server to fassert. When diagnosing a test failure, people are sometimes thrown off by seeing fassert backtraces in the logs for fasserts that are expected. If we create a server option to suppress backtraces for fasserts with certain codes, then the test use this option to prevent expected fasserts from appearing in the logs.



 Comments   
Comment by Githook User [ 30/May/17 ]

Author:

{u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}

Message: SERVER-27549 Better check for when a server has shut down
Branch: master
https://github.com/mongodb/mongo/commit/7b112f71fe551e92ae0a365f62fff402d4158035

Comment by Githook User [ 23/May/17 ]

Author:

{u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}

Message: SERVER-27549 Print message on intentional server crash.
Branch: master
https://github.com/mongodb/mongo/commit/df10adbfe55f21e3476be508436345e03b12fddc

Comment by Andy Schwerin [ 11/Jan/17 ]

I think having stopMongod log before that it expects a failure, and after that it found an expected failure would be helpful and a small amount of work. Changing the server to opt in to suppressing stack traces for certain failure codes is an interesting idea, but might be trickier than it seems to make useful.

I'd just do the extra logging.

Comment by Mathias Stearn [ 11/Jan/17 ]

I've manually added https://github.com/mongodb/mongo/blob/r3.4.1/jstests/replsets/oplog_replay_on_startup_with_bad_op.js#L64 because it was confusing that the last thing the test was supposed to do on success is fassert. jstests/replsets/oplog_replay_on_startup.js also has some "expected fatal" cases, but they were somewhat less confusing because there were passing cases after.

Comment by Max Hirschhorn [ 09/Jan/17 ]

schwerin, acm, this was an idea that came out of a conversation Tess and I had about how the fatal assertion triggered by this test case appears to be the cause of failures in set_feature_compatibility_version.js at first glance through the test logs. A similar confusion applies to other tests that intentionally cause the server to abort or otherwise exit uncleanly.

$ ag -l "allowedExitCodes" jstests/
jstests/noPassthrough/exit_logging.js
jstests/noPassthrough/minvalid2.js
jstests/replsets/initial_sync_invalid_index_spec.js
jstests/replsets/initial_sync_unsupported_auth_schema.js
jstests/replsets/invalid_index_spec.js
jstests/replsets/rollback_cmd_unrollbackable.js
jstests/replsets/rollback_collMod_fatal.js
jstests/replsets/rollback_dropdb.js
jstests/replsets/rollback_fake_cmd.js
jstests/replsets/rollback_too_new.js
jstests/sharding/remove2.js

Based on my conversation with robert.guo about how he's thinking of designing the tool to extract the "relevant logs" from failures, a message may be printed in MongoRunner.stopMongod() to indicate that a backtrace is expected. I wasn't sure if such a message would be sufficient for human readers to avoid confusion, or if you both thought that it'd be worth having tests opt-in to suppressing the backtrace for a specific location code at different parts of their execution.

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