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

Linked analyzers cannot be stopped: a stuck stack or concurrency analyzer stalls ctrace and its server

Open
  • Is something wrong?
#172 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp, python
Domain
devtools, testing

Research direction

Start with the external-tool timeout path referenced in the issue and the linked analyzer integration, then read docs/configuration.md and the timeout test coverage. Implement timeout handling for both linked analyzers so they are reported as failed with exit code 3, update the configuration documentation, and add a test that exercises the timeout path.

Written by the indexing model from the issue text.

Description

refactor severity/major

External tools stop after tools.<name>.timeout_s (#137, #156). The stack analyzer and the concurrency analyzer are linked into ctrace and run on its thread pool, so nothing can stop them: docs/configuration.md says so under tools.<name>.timeout_s.

Observed

On CoreTrace's own code, the pinned stack analyzer (v0.22.0) ran for 42 minutes without finishing (#169). The CLI only ends when something outside kills it, such as the CI job's time limit, and then gives no report. In server mode, the run_analysis request never returns and keeps a worker of the shared pool (#140).

Options

  1. Run each linked analyzer in a child process. ctrace re-executes itself with an internal subcommand and stops the child on timeout, as it does for external tools. The analyzers' API stays as it is; the cost is a process start and serializing the report, which is already structured (#66).
  2. A cancellation point in the analyzers, for example a stop token checked between functions or modules. There is no extra process, but both analyzers' APIs change, and a function stuck inside one fixed point still cannot be stopped.

Option 1 reuses the timeout path that external tools already have.

Acceptance

  • tools.ctrace_stack_analyzer.timeout_s and tools.coretrace-concurrency-analyzer.timeout_s stop the analyzer, which is reported as failed (exit code 3), as for external tools.
  • docs/configuration.md no longer says these two analyzers cannot be stopped.
  • A test covers the timeout path.

From the technical debt register (docs/quality/technical-debt.md, D2).

Dominant language
C++
Stars
5
Forks
4
Avg merge
1h 4m
Merged PRs (30d)
71

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 CoreTrace/coretrace

All issues in CoreTrace/coretrace

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.