Troubleshooting Synopsys Detect 6.4.0

Troubleshooting

• Troubleshooting best practices

  • Getting information 

  • Common problems

  • Incorrect or missing components

  • Spring boot related issues 

Troubleshooting is a systematic approach to solving a problem. The goal of troubleshooting is to determine why something does not work as expected and how to resolve the problem.

The information on this page is intended to provide troubleshooting tips when running scans with Synopsys Detect.

For help with more specific troubleshooting, use the following links to go to the relevant page.

• Exit Codes

• Diagnostic Mode

• Solutions to Common Problems

• Metrics and Code Verification

Troubleshooting best practices

The following information describes categories of troubleshooting help that help guide you towards a resolution of an issue.

Getting information 

• Run Synopsys Detect with --logging.level.com.synopsys.integration=DEBUG (the default logging level. INFO is insufficient for troubleshooting) and read through the entire log for clues.

• For more troubleshooting information: Run Synopsys Detect with the -d option, which generates a diagnostic zip that contains many useful intermediate files and logs, including the generated BDIO (.jsonld) files and Black Duck Signature Scanner logs.

• For more troubleshooting information, run Synopsys Detect with the -de option, which generates an extended diagnostic zip archive that also includes lock files and build artifacts when appropriate.

• For issues related to tools invoked by Synopsys Detect such as Black Duck Signature Scanner and Docker Inspector, check that tool's documentation.

Common problems

• Check if you can reproduce the problem using the latest version of Synopsys Detect with the latest version of Black Duck. If not, the problem might be either fixed, or because of incompatible Synopsys Detect / Black Duck versions.

• Remember to consider the possibility that the Black Duck user lacks the necessary permissions (to create the project, update the BOM, receive notifications, etc.) in Black Duck. For more information, refer to Black Duck user role requirements.

• Consider the possibility that the Black Duck server (registration key) may not have required capabilities enabled such as binary upload or snippet scanning.

Incorrect or missing components

• For issues related to incorrect components in the Black Duck BOM, Synopsys Detect has a lot of control over matches produced by detectors that are written to BDIO/.jsonld files, but no control over matches produced by the Black Duck Signature Scanner. When you investigate an incorrect component in a Black Duck BOM, you must determine whether the component was contributed by a detector, or by the Black Duck Signature Scanner.

  On the Black Duck Components tab for the project/version, Click on the "N Matches" link next to the component. The next screen lists the matches on the right side. Matches from the Black Duck Signature Scanner have a filename in the Name column. Matches from detectors have an external ID such as org.hamcrest:hamcrest-core:1.3 in the Name column.

• For issues related to components missing from or incorrectly categorized in the Black Duck BOM, Synopsys Detect has a great deal of control over the production of .jsonld files (use -d to save these), but no control over how they are converted into a BOM by Black Duck. A good first step is to determine whether the .jsonld files produced are correct. If they are incorrect, the problem is related to what Synopsys Detect is doing. If they are correct, but the BOM is incorrect, the problem is related to what Black Duck is doing. Similarly, Synopsys Detect is responsible for passing the correct arguments to the Black Duck Signature Scanner but has little control over the results it produces.

Spring boot related issues 

• Synopsys Detect is a Spring Boot application and leverages Spring Boot to provide various mechanisms to configure it through property settings. This flexibility comes with a risk such as the possibility for Synopsys Detect to be influenced by files (application.properties, and application.xml) that may exist in the directory from which Synopsys Detect is run but are intended for some other application. This can produce some strange results. If properties have unexpected values (refer to the Synopsys Detect log), this is a possibility worth considering. The best solution may be to run Synopsys Detect from a different (ideally empty) directory (use the --detect.source.path argument).

• Similarly, Synopsys Detect can be influenced by environment variables via the same Spring Boot mechanism, so it's a good practice to check the environment for variables that correspond to Synopsys Detect property names.