Repository navigation
What It Does Not Do
This tool is an early prototype, and the README says so: "the initial collection is intentionally basic". This page states the limits plainly, so the numbers are read for what they are.
Counters come from substring matches over log text — see Event Collection. There is no structured event stream between the runtime and the analyzer. Consequences:
- A change to a CoreTrace log message can change the counts without any behavior changing.
- Program output containing a matched substring is counted as a CoreTrace event.
- The counters overlap: a leak line is both an
allocation_eventand aleak_report, andheap-use-after-freeis counted underbounds_errorsalthough it is a lifetime error.
The summary is counters plus, with --show-events, the raw lines. There is no per-allocation
record, no call tree, no timeline, no correlation between an entry event and its matching exit.
There is no exit-code gate on findings, and no JSON or SARIF output. The exit code reflects
whether the tool ran and, in batch mode with --strict-test-exit, whether a test binary exited
non-zero — not whether the run detected a memory error.
A pipeline wanting a verdict has to read the counters itself.
One binary, one execution. No repeated runs, no input fuzzing, no coverage measurement, and no aggregation across invocations beyond batch mode summing its per-file summaries.
Development and the proof scripts target Unix-like systems. The Windows runtime work done in coretrace-compiler is not exercised here.
The last functional change to this repository landed in July 2026 (the minimal execution
tool, issue #4). issues/runtime-analyzer-implementation.md holds the implementation notes.
For mature analysis, the other CoreTrace tools are further along:
- coretrace-stack-analyzer — static stack and memory safety
- coretrace-concurrency-analyzer — concurrency rules
- coretrace-python-analyzer — Python security analysis
- coretrace — the orchestrator that runs them