This is a short story about how PVS-Studio helped us find an error in the source code of the library used in PVS-Studio. And it was not a theoretical error but an actual one — the error appeared in practice when using the library in the analyzer.In PVS-Studio_Cmd (as well as some other utilities) we use a special library for parsing command line arguments — CommandLine.Today I supported the new mode in PVS-Studio_Cmd and it so happened that I had to use this library for parsing command line arguments. While writing the code, I also debug it because I have to work with unfamiliar APIs.So, the code is written, compiled, executed and...

Code execution goes inside the library where an exception of thetype occurs. It's not so clear from the side — I don't pass any null references into the method.To be sure, I look at comments to the callee method. It is hardly probable that they describe the conditions of occurrence of an exception of thetype (as it seems to me usually exceptions of this type are not provided for).

There is no information aboutin the comments to the method (which, however, is expected).To see what exactly causes the exception (and where it occurs), I decided to download the project's source code, build it and add a reference to the debug version of the library to the analyzer. The source code of the project is available at GitHub . We need the version 1.9.71 of the library. It is the one used in the analyzer now.I download the corresponding version of the source code, build the library, add a reference to the debug library to the analyzer, execute the code and see:

private bool DoParseArgumentsVerbs( string[] args, object options, ref object verbInstance) { var verbs = ReflectionHelper.RetrievePropertyList<VerbOptionAttribute>(options); var helpInfo = ReflectionHelper.RetrieveMethod<HelpVerbOptionAttribute>(options); if (args.Length == 0) { if (helpInfo != null || _settings.HelpWriter != null) { DisplayHelpVerbText(options, helpInfo, null); // <= } return false; } .... }

helpInfo == null ;

; _settings.HelpWriter != null;

private void DisplayHelpVerbText( object options, Pair<MethodInfo, HelpVerbOptionAttribute> helpInfo, string verb) { string helpText; if (verb == null) { HelpVerbOptionAttribute.InvokeMethod(options, helpInfo, null, out helpText); } else { HelpVerbOptionAttribute.InvokeMethod(options, helpInfo, verb, out helpText); } if (_settings.HelpWriter != null) { _settings.HelpWriter.Write(helpText); } }

internal static void InvokeMethod( object target, Pair<MethodInfo, HelpVerbOptionAttribute> helpInfo, string verb, out string text) { text = null; var method = helpInfo.Left; if (!CheckMethodSignature(method)) { throw new MemberAccessException( SR.MemberAccessException_BadSignatureForHelpVerbOptionAttribute .FormatInvariant(method.Name)); } text = (string)method.Invoke(target, new object[] { verb }); }

So, the place where the exception occurs is clear —has avalue, which causes an exception of thetype when accessing theproperty.I started thinking about it. Recently, PVS-Studio for C# has been well improved in various aspects, including the search for dereferencing of potentially null references. In particular, the interprocedural analysis was improved in a number of ways. That's why I was immediately interested in checking the source code to understand if PVS-Studio could find the error under discussion.I checked the source code and among other warnings I saw exactly what I hoped for. V3080 Possible null dereference inside method at 'helpInfo.Left'. Consider inspecting the 2nd argument: helpInfo. Parser.cs 405Yeah, this is it! That's exactly what we need. Let's take a more detailed look at the source code.The analyzer issues a warning for calling themethod and warns about the second argument —. Pay attention that this method is located in the-branch of thestatement. The conditional expression is composed in such a way that the-branch can be executed at the next values of the variables:Let's see the body of themethod:Since(see method call) we are interested in-branch of thestatement. Although the situation is similar with thebranch, let's consider-branch because in our particular case the execution went through it. Remember thatmay beNow let's look at the body of themethod. Actually, you have already seen it on the screenshot above:is called unconditionally, whilemay be. The analyzer warned about it, and that's what happened.It is nice that we managed to find an error in the source code of the library used in PVS-Studio with the help of PVS-Studio. I think this is a kind of the answer to the question «Does PVS-Studio find errors in PVS-Studio source code?». :) The analyzer can find errors not only in PVS-Studio code but also in the code of the used libraries.Finally, I suggest you download the analyzer and try to check your project — what if you can find something interesting there too?