Skip to content

Latest commit

 

History

History
109 lines (71 loc) · 4.47 KB

BUG_REPORT.md

File metadata and controls

109 lines (71 loc) · 4.47 KB
Raw

Reporting bugs

Writing an effective bug report

When reporting a bug, start with the question What does a bug report need to tell the developer.

Generally you want the following parts covered:

  • What is the problem

  • How can the developer reproduce the problem (to see it for themselves), to bisect when it was introduced or to find if it got fixed already.

  • At what point does the problem occur

  • What environment did this occur in

Make sure the above items are covered and the bug is easy to review and parse:

  • Title should clearly describe the problem. Bugs are often sorted from the issue list which only contains the title

  • Logs should generally be attachments (drag & drop or click on bottom bar when entering issue text) and not inline with the issue.

  • Reproduction steps and environment should be clearly highlighted. If running commands reproduce the issue (very common), the commands should be in a code block/script format.

Describing the problem

Make sure the issue is obvious or provide a link explaining why the expected result is not met.

Examples:

  • (Core dump) seen is obvious since there should be no core dumps

  • Failure trying to read attribute X in cluster Y which is marked MANDATORY in the spec references the spec and describes why attribute read should succeed.

  • Failure trying to write attribute X in cluster Y, which is enabled since cluster FeatureMap enabled X and spec describes as writable. references the spec and explicitly states that an optional attribute is enabled based on device status

  • Running certification test TC-A-B-C (link included) fails at step 3: test case asks for command to succeed, I get ACCESS_DENIED instead describes a pre-defined test case that is expected to pass but fails. Note that full link to the test description is needed (and should be covered by 'how to reproduce' part)

Unless manually curated (e.g. few lines showing the problem), logs should be always attachments and not inlined in the bug as the make the bug report too long.

Reproduction steps and when does the issue occur

Include all steps needed to reproduce the problem. Link any supporting documentation.

If stating something of the form TC-A-B-C step 4 fails then there should be a link to TC-A-B-C and ideally a list of the commands of each step since test cases may change over time.

The bug report should contain all the information for a developer to reproduce the issue without needing to have access to CHIP Test case repository (not everyone does)

Environment for reproduction

Assume that the developer will want to reproduce the issue and will try to mirror your environment to a reasonable degree. For this, at a minimum the platforms on which everything is running is needed.

Try to provide as much information as seems relevant. At a minimum this could look like Failed to commission nrf board using chip-tool running on linux. Used build on SHA abcde.... This provides basic information (use nrf board, use chip-tool on linux, default build) to get started. Beyond that, you can refine if more items seem relevant:

  • Tested on TE9 or Tested on interop branch xyz gives a build reference point. Useful when branches/tags are used instead of master branch as development happens on master branch.

  • Thread devices fail, tested with qpg and efr32 shows that this seems to be a general thread issue and developer can investigate on multiple of them

  • Tested with avahi-build and it passes/fails helps the developer with information of non-default builds that pass/fail to narrow down the problem

  • Passes with darwin-framework-tool and repl but fails with chip-tool helps the developer in narrowing down the problem

Additional information

Providing additional information that can be helpful is encouraged. Each bug report is different here. Some examples:

  • This worked last week (around Jan 5) but started failing in recent master builds

  • Specification changed this attribute from optional to mandatory so this may be the cause of the issue

  • This issue may be related to #1234 as the same error is seen, however the reproduction steps seemed distinct enough that I opened a new issue

  • While running this, I observed 100% CPU before the operation finally timed out

  • While running this test, I observed device under test rebooting, logs attached.

  • This only happens intermittently - I see it about 30% of the time