I've discovered an issue with the way the cppcheck MISRA compliance checker works.
When cppcheck is running the misra.py addon, it generates an XML dump file for a translation unit and then runs misra.py passing the path to the dump file as an argument. The XML files contain the AST, token list, symbol database and value flow for the translation unit.
The problem is that for given source file <src>, the XML dump file is saved next to the source file as <src>.dump.
In a CMake/Ninja invocation with:
1. parallel jobs
2. multiple components building/compiling the same source files (e.g. building variants with different -D defines etc).
there can be a situation where more than one job to analyse the same translation unit occurs at the same time.
Since the generated XML dump file is created at a fixed location next to the source file it is derived from, multiple jobs can trample this file. When the first misra.py invocation completes, the XML dump is deleted. Any concurrent jobs using the same file can then fail.
For example here is an extract from a build log with two jobs involving the file components/pdk/tests/drivers/gpio/src/test_gpio_utils.c:
I straced the build and it confirms that the components/pdk/tests/drivers/gpio/src/test_gpio_utils.c.dump file was created (open with O_CREAT flag) by two different processes and then deleted (unlink) when the first process was finished with it.
Can I do anything to provide more info about this problem with .dump and .ctu-info file paths causing concurrency problems? I had a scan through the bug tracker but couldn't see this issue raised there, although I might have missed it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've discovered an issue with the way the
cppcheck
MISRA compliance checker works.When
cppcheck
is running themisra.py
addon, it generates an XML dump file for a translation unit and then runsmisra.py
passing the path to the dump file as an argument. The XML files contain the AST, token list, symbol database and value flow for the translation unit.The problem is that for given source file
<src>
, the XML dump file is saved next to the source file as<src>.dump
.In a CMake/Ninja invocation with:
1. parallel jobs
2. multiple components building/compiling the same source files (e.g. building variants with different
-D
defines etc).there can be a situation where more than one job to analyse the same translation unit occurs at the same time.
Since the generated XML dump file is created at a fixed location next to the source file it is derived from, multiple jobs can trample this file. When the first
misra.py
invocation completes, the XML dump is deleted. Any concurrent jobs using the same file can then fail.For example here is an extract from a build log with two jobs involving the file
components/pdk/tests/drivers/gpio/src/test_gpio_utils.c
:There is a build failure (see the Python crash backtrace at the bottom):
I straced the build and it confirms that the
components/pdk/tests/drivers/gpio/src/test_gpio_utils.c.dump
file was created (open
withO_CREAT
flag) by two different processes and then deleted (unlink
) when the first process was finished with it.The strace log file shows:
Suggestion
Change the path of the generated
.dump
files from<src>.dump
to/tmp/<uuid>.dump
or something like that.Note that there are also
.ctu-info
files generated at<src>.ctu-info
which also have the same problem.Can I do anything to provide more info about this problem with
.dump
and.ctu-info
file paths causing concurrency problems? I had a scan through the bug tracker but couldn't see this issue raised there, although I might have missed it.Fix implemented and PR merged here: https://github.com/danmar/cppcheck/pull/4757