Source Code

Use Source Code to investigate the root cause of an issue by integrating the source code associated with faulting frames in the stack trace.

Note: If you have Cloud Diagnostics Advanced or your source code deployed on-premises, you may need to deploy a backtrace-source-control service. For more information, reach out to Support.

Supported source control systems

The Source Code service will integrate with your cloud based or on-premises GIT and Perforce Helix-based systems. Reach out to our support team to learn more about on-premises deployments.

Managing source control

You can manage Repositories and Rules. Repositories are the source code repositories that the Source Code Integration Service will connect to to search for source code to display to the end user alongside the selected frames in the Debug view.

Rules are used when you want to nudge the source code integration service to choose one repository over another as it searches for the proper source code. Rules are not required, but useful if you see source code being displayed from the wrong repository.

Adding repositories

You can add as many repositories as you want to check for source code. For example, you can add your team’s private repositories that may be protected behind authentication, and any third-party public or private repositories for other components that you use (i.e. through github.com).

Once created, you'll see a small status icon to indicate the status of the Repository and what actions are being performed. The Source Code integration will attempt to connect and fetch to test URL and authentication information, and then begin to clone the repo. Error messages are provided when appropriate. It may take a few minutes to clone large repositories.

To add a repository, go to your project’s Settings > Source code > Add a repository.

Git-based systems

The following is required to connect to a Git-bases system, like GitHub:

  • Connection Information: Backtrace Source Control can integrate with GIT based systems. You must provide a Name, URL (HTTP or SSH based), and Authentication method (None, Username / Password, SSH Key).

    • Note: You may need to work with your source control system to get the proper URL and credentials to provide access to your SCM.
  • Revisions: GIT systems take snapshots of the source code at different times and manage those as Revisions. You can specify the ordered list of Revisions to try when searching for matching source code. Acceptable revision types include branch names, tags, as well as short and long SHA-1 hashes. You can specify an attribute to be dynamically included in the revision string by using {attribute} template syntax.

By default, we'll check the main branch, but we expect you will want to specify more granular branches to be checked first. For example, a common pattern is to have 'release/{application}/{version}' as a standard way to tag releases. Other examples:

  • release/{version}
  • {commit}
  • 729e0d9a
  • master
  • main

The Source Code integration will search these revisions within the repository in order to fetch the appropriate source code.

Perforce-based systems

The following is required to connect to a Perforce-based system:

  • Connection Information: Backtrace Source Control can integrate with Perforce systems using the p4 command line utility. You must provide a Name, Host and Port, Username and Password.
  • Source Code Depot Paths: You’ll need to specify a list of depot paths to try, in order, when searching for matching source code.

You can specify an attribute to be dynamically included in the path by using {attribute} template syntax. For example, you might choose to first search "//depot/releases/{version}/" followed by "//depot/develop/". If the version attribute is set to '1.15' on the error that you are inspecting, then it’ll be used to create a search path of "//depot/releases/1.15/". Some examples:

  • //depot/project/release/{version}
  • //depot/project/main/
  • //depot/project/develop/

The Source Control integration will search these depot paths in order to fetch the appropriate source code.

Using source code

Once configured, a Source tab will be available in the Debug view for all errors in a project. You can navigate through frames to see source code if it can be found. We'll identify the file name and path, which Repository and revision it came from, and the date that revision was published.

You can navigate up and down, jump back to the highlighted line, and optionally show time that each line was committed, who did that commit, and the commit hash.

Some frames will get a 'Not enough information to locate source code'. That means that there is not enough information in the frame to find the source code in the defined repositories. You might not have this source code available in the defined repositories.

Multiple repositories and rules

By default, each repository is searched in sequential order to try to find relevant source code. If you see incorrect information being displayed, you can "Add a rule" to nudge the system to one repository over another.

Rules have the following format: "if a <attribute / file name / function name / object name> has a certain value, use or skip a specific repository”. For example, "If the module name is regular expression libc.*so, then use repository glibc".