cppcheck | static analysis of C/C++ code | Code Analyzer library

You can find an answer here: https://github.com/kwin/cppcheclipse/issues/108

and the following download link here.

So work-around to install the plugin:

This is indeed a false positive and it is fixed in the upcoming Cppcheck 2.7. I can reproduce it with 2.6 but not with the latest head.

Looking at the list of fixed issues it appears you encountered https://trac.cppcheck.net/ticket/10485.

The problem was that .h files where still checked, despite -i flag. Solution:

How to install an .msi program in Azure Pipeline (Windows)

You could use the Powershell task to install the .msi file:

This is definitely a stack overflow. sizeof(dynamic_loop_functor_t) is nearly 64 MiB, and the default stack size limit on most Linux distributions is only 8 MiB. So the crash is not surprising.

The remaining question is, why does the debugger identify the crash as coming from inside std::operator<<? The actual segfault results from the CPU exception raised by the first instruction to access to an address beyond the stack limit. The debugger only gets the address of the faulting instruction, and has to use the debug information provided by the compiler to associate this with a particular line of source code.

The results of this process are not always intuitive. There is not always a clear correspondence between instructions and source lines, especially when the optimizer may reorder instructions or combine code coming from different lines. Also, there are many cases where a bug or problem with one source line can cause a fault in another section of code that is otherwise innocent. So the source line shown by the debugger should always be taken with a grain of salt.

In this case, what happened is as follows.

• The compiler determines the total amount of stack space to be needed by all local variables, and allocates it by subtracting this number from the stack pointer at the very beginning of the function, in the prologue. This is more efficient than doing a separate allocation for each local variable at the point of its declaration. (Note that constructors, if any, are not called until the point in the code where the variable's declaration actually appears.)

  The prologue code is typically not associated with any particular line of source code, or maybe with the line containing the function's opening {. But in any case, subtracting from the stack pointer is a pure register operation; it does not access memory and therefore cannot cause a segfault by itself. Nonetheless, the stack pointer is now pointing outside the area mapped for the stack, so the next attempt to access memory near the stack pointer will segfault.

• The next few instructions of main execute the cout << "Starting main". This is conceptually a call to the overloaded operator<< from the standard library; but in GCC's libstdc++, the operator<< is a very short function that simply calls an internal helper function named __ostream_insert. Since it is so short, the compiler decides to inline operator<< into main, and so main actually contains a call to __ostream_insert. This is the instruction that faults: the x86 call instruction pushes a return address to the stack, and the stack pointer, as noted, is out of bounds.

  Now the instructions that set up arguments and call __ostream_insert are marked by the debug info as corresponding to the source of operator<<, in the header file - even though those instructions have been inlined into main. Hence your debugger shows the crash as having occurred "inside" operator<<.

  Had the compiler not inlined operator<< (e.g. if you compile without optimization), then main would have contained an actual call to operator<<, and this call is what would have crashed. In that case the traceback would have pointed to the cout << "Starting main" line in main itself - misleading in a different way.

Note that you can have GCC warn you about functions that use a large amount of stack with the options -Wstack-usage=NNN or -Wframe-larger-than=NNN. These are not enabled by -Wall, but could be useful to add to your build, especially if you expect to use large local objects. Specifying either of them, with a reasonable number for NNN (say 4000000), I get a warning on your main function.

The pattern /Godot.app should match your file just fine. However, if the file is already added to the repository, then .gitignore has no effect on it. The .gitignore file affects only files which are untracked.

In your case, your file is in the history, and it needs to be removed from the entire history if you want to upload it to GitHub. You can do a git rebase -i to go back in history to the point at which it was added and remove it from history, or, if it was added in the most recent commit, you can remove it with git rm -r Godot.app and then run git commit --amend.

You could also use git filter-branch or git filter-repo to filter it out from the history.

When you do

You can't set CMAKE_TOOLCHAIN_FILE after the call to project(). That's the command responsible for loading the toolchain file in the first place. Move it before the call to project() or better yet: set it at the command line or in a preset.

Also, unless you're actually using CMake 3.0.0, you shouldn't set it as a minimum. CMake is not forwards compatible, so without actually testing it on the minimum version, you have no way of knowing whether it will work that far back.

I found this comment https://sourceforge.net/p/cppcheck/discussion/general/thread/b18f7aaf/#d726

It will be fixed in the next release. For now I have disabled the check. But it can be enabled again if we write such warnings properly. The checker must ensure that the class is a base class!

The post relates to 1.84

Looking at the code it is still disabled: https://github.com/danmar/cppcheck/blob/6397e29f84de53655904326ef1ca892a509275c5/lib/checkclass.h