Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Reports analysed on Linux are silently discarded by a server on Windows

Open
#5,112 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
linux, python
Domain
backend, databases

Research direction

Pull request #5111 already contains the four fixes described here, so review that work rather than starting a separate implementation. The issue identifies plist.py, mass_store_run.py, server.py and cli/server.py as relevant entry points; verify the Windows server can start, store Linux reports with a nonzero resultCount, and shut down cleanly.

Written by the indexing model from the issue text.

Description

Storing reports produced by an analysis on Linux to a CodeChecker server
running on Windows results in an empty run: the run, its history and the
analyzer statistics are stored, but resultCount stays 0 and no report is ever
visible.

Nothing reports a failure. The client prints "Storing the reports finished
successfully", the server-side task is marked COMPLETED, and the pipeline sees
a successful store. The only trace is a warning on the server's own console:

Failed to get database id for file path 'C:\home\user\project\a.cpp'!
Skip adding report: ...

This makes a quality gate built on net-new findings compare two empty sets, so
it reports healthy while enforcing nothing.

Cause

plist.py resolves each file path in a report against the directory the
uploaded ZIP was extracted into:

file_path = os.path.normpath(os.path.join(source_dir_path, orig_file_path))

On POSIX an absolute path discards the left side of the join and passes through
unchanged. On Windows a leading / means "root of the current drive", so the
drive letter is grafted on and the separators flipped, turning
/home/user/project/a.cpp into C:\home\user\project\a.cpp. The file
records are keyed on the original path, so the lookup in mass_store_run.py
misses and every report is skipped.

This is #3654 in the opposite direction, which shows the problem is symmetric
rather than specific to Windows-style paths. #3814 reports the same symptom.

Three further problems on the way

A Windows server cannot be reached at all without fixing these first, which may
explain why #3654 has not been reproduced:

  1. The server does not start. Pool(max_workers=...) is passed to
    multiprocess.Pool, which takes processes=. The two Pool types also
    differ in map(): one takes a single iterable, the other *iterables, so
    the call cannot be made portable by changing the keyword alone.
    TypeError at server.py:602 and cli/server.py:723 (product creation).

  2. The background task worker dies immediately. It registers a SIGHUP
    handler, which does not exist on Windows, so it exits with AttributeError
    before consuming anything. Report storage happens only in these workers, so
    store then hangs or fails with Database error on server. server.py
    already guards SIGHUP elsewhere.

  3. Shutdown hangs. With no SIGHUP handler nothing sets kill_flag, so
    the worker never exits its loop and join() blocks on Ctrl+C, leaving the
    port bound. The parent already sets a shared shutdown flag and passes it to
    the worker, but the worker only reads it after the loop.

Environment
  • CodeChecker 6.29.x, server on Windows, analysis on Linux
  • Reports stored over the network from a containerised analysis
Fix

A pull request with all four fixes is open as #5111. The POSIX code paths are
unchanged, pycodestyle is clean, and the change is verified on one server
with the same client and reports — resultCount 0 before, 3 after.

Review and feedback would be appreciated.

Dominant language
Python
Stars
2.6k
Forks
494
Avg merge
3d 1h
Merged PRs (30d)
20

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Ericsson/codechecker

All issues in Ericsson/codechecker

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.