When running MISRA C checks on a third party codebase, cppcheck fails on some of the files with an internalError somewhere in the MISRA Python files. Cppcheck verson is 2.4.1.
This is an example output (XML format) with project specific filenames/paths redacted:
<errorid="internalError"severity="information"msg="Bailing out from checking [filename redacted].c since there was an internal error: Failed to execute 'python3 /usr/share/cppcheck/addons/misra.py --cli --rule-texts=[path redacted]/misra_rules.txt --suppress-rules=11.4,11.5,15.5,3.1,11.3,11.6 [filename redacted].c.dump'. Traceback (most recent call last):"verbose=" File "/usr/share/cppcheck/addons/misra.py", line 3327, in <module>\n main()\n File "/usr/share/cppcheck/addons/misra.py", line 3271, in main\n checker.parseDump(item)\n File "/usr/share/cppcheck/addons/misra.py", line 3102, in parseDump\n self.executeCheck(902, self.misra_9_2, cfg)\n File "/usr/share/cppcheck/addons/misra.py", line 3053, in executeCheck\n check_function(*args)\n File "/usr/share/cppcheck/addons/misra.py", line 1499, in misra_9_2\n misra_9.misra_9_x(self, data, 902)\n File "/usr/share/cppcheck/addons/misra_9.py", line 406, in misra_9_x\n parser.parseInitializer(ed, eq.astOperand2)\n File "/usr/share/cppcheck/addons/misra_9.py", line 305, in parseInitializer\n elif self.token.isString and self.ed.valueType.pointer > 0:\nAttributeError: 'NoneType' object has no attribute 'pointer'\n"><locationfile="[filename redacted].c"line="0"column="0"/></error>
Hello, thanks for reporting this.
The third-party codebase you're talking about is open source? Can you show the code where the misra.py crashes or provide a minimal example?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<?xml version="1.0" encoding="UTF-8"?><resultsversion="2"><cppcheckversion="2.4.1"/><errors>
Checking test.c ...
<errorid="internalError"severity="information"msg="Bailing out from checking test.c since there was an internal error: Failed to execute 'python3 /usr/share/cppcheck/addons/misra.py --cli test.c.dump'. Traceback (most recent call last):"verbose=" File "/usr/share/cppcheck/addons/misra.py", line 3327, in <module>\012 main()\012 File "/usr/share/cppcheck/addons/misra.py", line 3271, in main\012 checker.parseDump(item)\012 File "/usr/share/cppcheck/addons/misra.py", line 3102, in parseDump\012 self.executeCheck(902, self.misra_9_2, cfg)\012 File "/usr/share/cppcheck/addons/misra.py", line 3053, in executeCheck\012 check_function(*args)\012 File "/usr/share/cppcheck/addons/misra.py", line 1499, in misra_9_2\012 misra_9.misra_9_x(self, data, 902)\012 File "/usr/share/cppcheck/addons/misra_9.py", line 406, in misra_9_x\012 parser.parseInitializer(ed, eq.astOperand2)\012 File "/usr/share/cppcheck/addons/misra_9.py", line 305, in parseInitializer\012 elif self.token.isString and self.ed.valueType.pointer > 0:\012AttributeError: 'NoneType' object has no attribute 'pointer'\012"><locationfile="test.c"line="0"column="0"/></error><errorid="missingInclude"severity="information"msg="Cppcheck cannot find all the include files (use --check-config for details)"verbose="Cppcheck cannot find all the include files. Cppcheck can check the code without the include files found. But the results will probably be more accurate if all the include files are found. Please check your project's include directories and add all of them as include directories for Cppcheck. To see what files Cppcheck cannot find use --check-config."/></errors></results>
I think the problem is related to the missing include which holds the datatypes. Replacing "MY_UINT08" by "unsigned char" makes the internalError go away. Missing includes certainly require attention, but the internalError is likely not the desired behaviour.
I hope this helps in reproducing the error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In this example, there is no datatypes.h (or at least, it is not in the include paths given to cppcheck). If there were one, it would look like in your example.
However, I think the fact that cppcheck doesn't know more about the MY_UINT08 type is what is actually causing the crash.
One could argue that the datatypes.h file should always be provided to cppcheck, so that it would just know the type. But probably a more graceful means of handling this situation is intended than the crash observed here, when the definition is not given.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
$ ./cppcheck --enable=all --addon=misra.py --xml test.c
<?xml version="1.0" encoding="UTF-8"?><resultsversion="2"><cppcheckversion="2.4"/><errors>
Checking test.c ...
<errorid="misra-c2012-9.2"severity="style"msg="misra violation (use --rule-texts=<file> to get proper output)"verbose="misra violation (use --rule-texts=<file> to get proper output)"file0="test.c"><locationfile="test.c"line="7"column="29"/></error><errorid="missingInclude"severity="information"msg="Cppcheck cannot find all the include files (use --check-config for details)"verbose="Cppcheck cannot find all the include files. Cppcheck can check the code without the include files found. But the results will probably be more accurate if all the include files are found. Please check your project's include directories and add all of them as include directories for Cppcheck. To see what files Cppcheck cannot find use --check-config."/></errors></results>
I doubt that the internal error is related to the misra addon. you should see such error if you remove the --addon=misra also.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My colleague tried the "bf019a" version and we can confirm the issue is now fixed. Thanks for the support and apologies for the confusion. It appears that his previous build still used a version just before the relevant fixes ("e3b7ce").
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When running MISRA C checks on a third party codebase, cppcheck fails on some of the files with an internalError somewhere in the MISRA Python files. Cppcheck verson is 2.4.1.
This is an example output (XML format) with project specific filenames/paths redacted:
After clean-up, this becomes:
Due to time constraints, I can't try to extract an simple example case to trigger the behaviour at this time.
If needed, can look into this later.
Last edit: khouri 2021-03-30
Hello, thanks for reporting this.
The third-party codebase you're talking about is open source? Can you show the code where the misra.py crashes or provide a minimal example?
This is not an open source code base. I also can't share the file itself, but I can try to create a minimal example soon (after deadlines).
Take a look at my comments on the same sort of error
https://sourceforge.net/p/cppcheck/discussion/development/thread/0c9cff17b7/
Are your errors on a similar type structure init?
All of the affected files have several similar initialisations - structs with named members - happening as what you described in your post: https://sourceforge.net/p/cppcheck/discussion/development/thread/0c9cff17b7/#0b66/c8ca/70ae/99d1/114d/6bec/5fae/01aa/6f0f/f2c6
In our case, the structs are not packed, but the overall code usage is otherwise very similar.
One of our interns dived into this (thx, Sander!) and we've managed to extract a minimum viable way of recreating the bug. Cppcheck version is 2.4.1.
test.c:
cppcheck command:
Yields as output:
I think the problem is related to the missing include which holds the datatypes. Replacing "MY_UINT08" by "unsigned char" makes the internalError go away. Missing includes certainly require attention, but the internalError is likely not the desired behaviour.
I hope this helps in reproducing the error.
Thanks for this minimal example.
Could you please show how
MY_UINT08
is defined in datatypes.h?I've tried to add the following lines to datatypes.h, but it doesn't produce any false positives:
In this example, there is no datatypes.h (or at least, it is not in the include paths given to cppcheck). If there were one, it would look like in your example.
However, I think the fact that cppcheck doesn't know more about the MY_UINT08 type is what is actually causing the crash.
One could argue that the datatypes.h file should always be provided to cppcheck, so that it would just know the type. But probably a more graceful means of handling this situation is intended than the crash observed here, when the definition is not given.
Thanks, here is suggested fix: https://github.com/danmar/cppcheck/pull/3305 .
Last edit: Georgiy Komarov 2021-06-24
I think you may have missed this in the other thread. The following update to the test file will produce the problem.
That was intended for Georgiy. Sorry if it appears like it is directed at khouri.
Thanks, it seems to be fixed in the main branch: https://github.com/danmar/cppcheck/pull/3290 .
My colleague just tested the updated cppcheck with a fresh build from the commit mentioned in the post above (thus incl. the fix).
Using the test.c file described earlier as input, I'm sorry to say the internalError still persists.
I can't reproduce the internal error neither.
When I test it with latest HEAD;
I doubt that the internal error is related to the misra addon. you should see such error if you remove the
--addon=misra
also.I can't reproduce this with cppcheck from the main branch (commit bf019a) too.
Could you please provide details info about the internal error, if it appears in the closed-source code base so that we can reproduce it?
My colleague tried the "bf019a" version and we can confirm the issue is now fixed. Thanks for the support and apologies for the confusion. It appears that his previous build still used a version just before the relevant fixes ("e3b7ce").