[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: |
|
||||||||||||
| 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 descriptionSome 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: | ||||||||||||
| 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: | ||||||||||||
| 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.
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. |