Incorrect processing of similar entries in compilation database

[ChGen]

Describe the bug
In case compile_commands.json contains entries with the same file field value, analyzers may write to the same output plist file and provide corrupted or overwritten results for the entries.

CodeChecker version
6.25.1

To Reproduce
Steps to reproduce the behaviour:

1. Prepare openssl v3.3.1 sources
2. Prepare compilation database:

mkdir /w/openssl-3.3.1/bld && cd /w/openssl-3.3.1/bld
../Configure --debug && bear -- make -rj$(cat /proc/cpuinfo|grep -c processor)

3. Run CodeChecker:

CodeChecker analyze --analyzers clangsa ... ./compile_commands.json -o ./result_clangsa/

4. See errors during checking like:

Traceback (most recent call last):
  File "/root/.local/share/pipx/venvs/codechecker/lib/python3.12/site-packages/codechecker_analyzer/analysis_manager.py", line 560, in check
    source_analyzer.post_analyze(rh)
  File "/root/.local/share/pipx/venvs/codechecker/lib/python3.12/site-packages/codechecker_analyzer/analyzers/clangsa/analyzer.py", line 342, in post_analyze
    plist = plistlib.load(f)
            ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/plistlib.py", line 884, in load
    return p.parse(fp)
           ^^^^^^^^^^^
  File "/usr/lib/python3.12/plistlib.py", line 186, in parse
    self.parser.ParseFile(fileobj)
xml.parsers.expat.ExpatError: unclosed token: line 14630, column 17
...
xml.parsers.expat.ExpatError: no element found: line 11968, column 34
...
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 26, column 0
...
xml.parsers.expat.ExpatError: mismatched tag: line 448, column 4

5. Check that compile_commands.json contain two entries for source file /w/openssl-3.3.1/apps/ca.c with different output file names.
6. Check that some of the plist files in ./result_clangsa/ are damaged due to concurrent writes from several instances of the analyzer.
7. Single threaded checking via CodeChecker analyze -j 1 ... will finish successfully, demonstrating concurrency issue.

Expected behaviour
Compilation database entries with the same source file name should be checked separately and write results to different output plist files.

Desktop (please complete the following information)

• CPU: Intel Core i7-13700, 24 threads
• OS: Linux, Ubuntu 24.04 LTS
• Python 3.12
• CodeChecker 6.25.1

[bruntib]

Hi,

Thanks for the report. Unfortunately, I can't reproduce the issue. Could you, please, try to apply this patch and check if the problem still occurs?
#4632

Thank you!

[ChGen]

@bruntib , It still fails in the anayzer.py:371. Note that there's lengthy comment there about this issue.
I've tried also to add locking there (keeping also locking changes in plist.py) , but it didn't help:

-            with open(result_handler.analyzer_result_file, 'rb') as f:
+            with portalocker.Lock(result_handler.analyzer_result_file, 'rb') as f:

Is this locking API fully supported in modern Linux inside docker containers? Or maybe I use it incorrectly here?

[ChGen]

Note that increasing jobs count above available CPUs increases chance of this bug: CodeChecker analyze -j 32 ... # 32 for 24 cores CPU.

[bruntib]

I still couldn't reproduce the issue. I would think that "file write" operations should be locked in order to prevent concurrent writes, since the file content is mixed as you mentioned. By the way, how does such a plist file look like? Is it explicitly visible that its lines are mixed?

[ChGen]

Yes, it sometimes visible after execution. Below is file fragment, key>macro_expansions</key> ... starts after </plist> tag:

ca.c_clangsa_31c6d42d300a42db7f4d6c8826037995.plist

...
	<key>metadata</key>
	<dict>
		<key>analyzer</key>
		<dict>
			<key>name</key>
			<string>clangsa</string>
		</dict>
		<key>generated_by</key>
		<dict>
			<key>name</key>
			<string>CodeChecker</string>
			<key>version</key>
			<string>6.25.1</string>
		</dict>
	</dict>
</dict>
</plist>
key>macro_expansions</key>
   <array>
   </array>
   <key>description</key><string>...</string>
   <key>category</key><string>...</string>
   <key>type</key><string>...</string>
   <key>check_name</key><string>...</string>
   <!-- This hash is experimental and going to change! -->
   <key>issue_hash_content_of_line_in_context</key><string>8375bdf083b12d7983c1fc0dc80f7de9</string>
  <key>issue_context_kind</key><string>function</string>
  <key>issue_context</key><string>...</string>
  <key>issue_hash_function_offset</key><string>0</string>
  <key>location</key>
...