Ivan Kishchenko

Oct 13 2016

Tags:

#CSharp

GitExtensions bugs found and analyzed

• GitExtensions
• The analysis results
  • An expression that is always true
  • One of the comparisons is superfluous
  • The variable is used before the verification against null
  • There is the possibility of an exception NullReferenceException in the overridden method Equals
  • Identical expressions in the if condition
  • Unequal number of parameters during string formatting
  • A part of the expression is always true
• Conclusion

As it is known, the Git kernel is a utility set of a command line with parameters. Usually, we use utilities that provide us with a familiar graphical interface, for comfortable work. I also happened to work with the Git utility, 'GitExtensions'. I would not say that this is the most convenient tool that I have used in my work (I liked TortoiseGit much more), but it it has full right to a place in the list of my favorite and most trusted utilities to work with Git.

Recently, I decided to check it with a static analyzer to see if it has any bugs or typos in the source code. This article is about those errors that were found in that check.

GitExtensions

GitExtensions is a cross-platform visual client for working with the Git version control system, open source.

The GitExtensions project is rather small. In total there are 10 main projects, 20 plugins, and 2 additional projects, all of which get compiled into auxiliary libraries. In general there are 56 091 lines of code in 441 files.

Let's see if PVS-Studio is able to find anything of interest to us in this project.

The analysis results

The result of the check was about 121 warnings. To be more precise, there were 16 first level warnings (high risk). 11 of them clearly pointed to a problem fragment or an error. There were also 80 second level warnings (medium risk). In my subjective opinion, 69 of these warnings were correct, and indicated fragments that contained real bugs or typos. We aren't going to cover third level warnings in this article, because quite often they indicate fragments where the errors aren't very likely to happen. So, let's look at the bugs found.

An expression that is always true

Quite a strange code fragment opens the chart:

string rev1 = "";
string rev2 = "";

var revisions = RevisionGrid.GetSelectedRevisions();
if (revisions.Count > 0)
{
  rev1 = ....;
  rev2 = ....;
  ....
}
else

if (string.IsNullOrEmpty(rev1) || string.IsNullOrEmpty(rev2)) // <=
{
    MessageBox.Show(....);
    return;
}

V3022 Expression 'string.IsNullOrEmpty(rev1) || string.IsNullOrEmpty(rev2)' is always true. GitUI FormFormatPatch.cs 155

The analyzer issued a warning that the expression with the check of the variables rev1 and rev2 is always true. At first I thought it was a normal typo, a little flaw in the logic of the algorithm, which does not affect the correctness of the program in any way. But after taking a closer look, I noticed that apparently, there is an extra else statement. It is located before the second check, which will be done only in case of the first being false.

One of the comparisons is superfluous

The second place in our chart is a simple typo. It does not affect the logic of the program, but this example shows really well how useful static analysis is.

public void EditNotes(string revision)
{
  string editor = GetEffectivePathSetting("core.editor").ToLower();
  if (editor.Contains("gitextensions") || 
      editor.Contains("notepad") || // <=
      editor.Contains("notepad++")) // <=
  {
    RunGitCmd("notes edit " + revision);
  }
  ....
}

V3053 An excessive expression. Examine the substrings 'notepad' and 'notepad++'. GitCommands GitModule.cs 691

A longer (notepad++), and a shorter (notepad), substring are searched for in the subexpression. At the same time the check with the longer string will never work, because the check with the search for a shorter string will prevent it. As I mentioned, it's not a bug, just a typo, but in another situation the innocent redundant check could turn into a potentially treacherous bug.

The variable is used before the verification against null

The third place belongs to a fairly common error, but I cannot say for sure that it will cause the program to work incorrectly, because I haven't dug too deep in the program code. The mere fact that the variable is verified against null signals a probable null value.

void DataReceived(string data)
{
  if (data.StartsWith(CommitBegin)) // <=
  {
      ....
  }
  
  if (!string.IsNullOrEmpty(data))
  {
      ....
  }
}

V3095 The 'data' object was used before it was verified against null. Check lines: 319, 376. GitCommands RevisionGraph.cs 319

The variable data is used before the verification against null, which can potentially cause the exception NullReferenceException. If the data variable is never null, then the verification below it is useless and should be removed so that it doesn't mislead people.

There is the possibility of an exception NullReferenceException in the overridden method Equals

This bug is a lot like the previous one. If you compare two objects using an overridden Equals method, there is always the possibility that you may get null as the second comparison object.

public override bool Equals(object obj)
{
  return GetHashCode() == obj.GetHashCode(); // <=
}

V3115 Passing 'null' to 'Equals(object obj)' method should not result in 'NullReferenceException'. Git.hub User.cs 16

While continuing to call the overridden Equals method, you may get the exception NullReferenceException if the parameter obj is null. To prevent such a situation, you should use a check against null. Like this for instance:

public override bool Equals(object obj)
{
  return GetHashCode() == obj?.GetHashCode(); // <=
}

Identical expressions in the if condition

Two typos have proudly taken fifth place. They affect the program in no way, but we can categorize them as redundant checks.

private void ConfigureRemotes()
{
  ....
  if (!remoteHead.IsRemote ||
    localHead.IsRemote ||
    !string.IsNullOrEmpty(localHead.GetTrackingRemote(localConfig)) ||
    !string.IsNullOrEmpty(localHead.GetTrackingRemote(localConfig)) ||
    remoteHead.IsTag ||
    localHead.IsTag ||
    !remoteHead.Name.ToLower().Contains(localHead.Name.ToLower()) ||
    !remoteHead.Name.ToLower().Contains(_remote.ToLower()))
    continue;
  ....
}

V3001 There are identical sub-expressions to the left and to the right of the '||' operator. GitUI FormRemotes.cs 192

If you take a close look at the code, you may notice two identical conditions in the check. This is most likey due to copy-paste. Also there is the probability of an error, if we take into consideration that in the second subexpression it was supposed to use the localHead variable instead of remoteHead, but it's hard to say for sure without doing an in-depth analysis of the program algorithm.

One more similar error was found:

if (!curItem.IsSourceEqual(item.NeutralValue) && // <=
  (!String.IsNullOrEmpty(curItem.TranslatedValue) && 
  !curItem.IsSourceEqual(item.NeutralValue))) // <=
{
  curItem.TranslatedValue = "";
}

V3001 There are identical sub-expressions to the left and to the right of the '&&' operator. TranslationApp TranslationHelpers.cs 112

Unequal number of parameters during string formatting

Sixth place goes to quite a common error, which occurs because of the inattentiveness of programmers during text refactoring of the formatted strings.

Debug.WriteLine("Loading plugin...", pluginFile.Name); // <=

V3025 Incorrect format. A different number of format items is expected while calling 'WriteLine' function. Arguments not used: pluginFile.Name. GitUI LoadPlugins.cs 35

In this situation, I assume that the programmer thought the value of the variable pluginFile.Name would be added to the end of the formatted string upon the debug output, but it is not so. The correct code should be:

Debug.WriteLine("Loading '{0}' plugin...", pluginFile.Name); // <=

A part of the expression is always true

Finally, here is another typo, which could have been avoided.

private void toolStripButton(...)
{
  var button = (ToolStripButton)sender;
  if (!button.Enabled)
  {
    StashMessage.ReadOnly = true;
  }
  else if (button.Enabled && button.Checked) // <=
  {
    StashMessage.ReadOnly = false;
  }
}

V3063 A part of conditional expression is always true if it is evaluated: button.Enabled. GitUI FormStash.cs 301

Since we check that button.Enabled is false, then in the else clause of this verification, we can safely say that button.Enabled is true, and thus delete this check again.

Conclusion

There were many more errors, typos, and issues found in this project. But they didn't seem worth describing in this article. GitExtensions developers can easily find all the issues, using the PVS-Studio tool. You may also find bugs in your projects with the help of the aforementioned tool.

I would like to mention that the biggest benefit of static analysis is to be found with its regular use. It's not serious to download the tool and do the one-time check. As an analogy, programmers regularly review the compiler warnings, not like 3 times a year before the release. If the analyzer is used on a regular basis, it will significantly save time that is usually spent on searching for typos and errors.

#CSharp

0

0

0

0

SHARE

Tags:

#CSharp

We can email you a selection of our best articles once a month