Proof

Every claim, checked.

Public incidents where the log did not say what broke, the bottom of a real report, and every number with where it comes from.

8 public threads where the log did not say what broke.

Open any of them. The engineer's own words, with their name. The TrialONE line is our real output on that log — not a rewrite.

ros_controllers#561Differential-drive AMR, ROS 2 · diff_drive_controller
The controller intermittently commands motion nobody asked for.
The log points at
Nothing. No error, no warning — the recording looks like a normal run, which is why the thread never resolved it.
What the engineer found
The system clock stepped backwards after boot, once NTP corrected it. The controller saw a negative dt.
TrialONE said
/tr_velocity_controller/odom carries 61 message timestamps EARLIER than the message before it on the same topic, the largest going back 1.336 s, first at t = 3.4 s.
Read the whole answerShow less
This compares one clock against itself, so it is not a threshold or a deviation: a timestamp cannot precede its predecessor.
still open · unresolved on GitHubOpen the thread
NVIDIA forum 237121Jetson carrier board · Wi-Fi drops, thermal warnings
Wi-Fi scanning breaks after a while; the board reports thermal sensor failures.
The log points at
The IOMMU and the thermal subsystem. The visible errors are SMMU page-table warnings and soctherm sensor failures — two subsystems that are not the cause.
What the engineer found
A proprietary out-of-tree r8168 Ethernet driver was leaking DMA mappings. Not the IOMMU, not thermal.
TrialONE said
The root cause is a DMA mapping leak in the proprietary out-of-tree r8168 Ethernet driver (8.045.08-NAPI).
Read the whole answerShow less
It repeatedly maps the same IOVA (0x00000000feddf000) through the Tegra SMMU without unmapping it, triggering 'error: map req on already mapped pte' at tegra-smmu.c:901 and corrupting the page table for ASID=10 — the PCIe domain.
resolved in the forum threadOpen the thread
cyclonedds#1548Distributed multi-process ROS 2 system · CycloneDDS 0.10.2
Restarting one process reproducibly crashes one, several, or all of the others.
The log points at
A Fibonacci heap. Both backtraces end inside fibheap.c — a data-structure implementation that is not the defect.
What the engineer found
A race in the DDS security state machine: the overall-timeout path and the event handler reach the same node from opposite ends.
TrialONE said
EVERY stack in this dump passes through dds_security_fsm.c — the crashing structure is not the common factor, its caller is.
Read the whole answerShow less
Two threads reaching one structure through the same caller and failing at opposite ends of it (one inserting, one extracting) is the signature of an ordering problem in that caller, not a defect in the structure. Start there.
maintainer diagnosis in the threadOpen the thread
navigation2#2373Custom robot · Nav2 voxel layer, stereo point cloud
controller_server and planner_server die with a segmentation fault at random.
The log points at
A lifecycle shutdown. The manager reports the node stopped answering — upstream code behaving exactly as designed.
What the engineer found
Out-of-bounds access in raytraceLine(): a double → int → double conversion lost precision on the clipping bounds.
TrialONE said
'controller_server' stopped answering its heartbeat for 4.0 s and the lifecycle manager shut the stack down.
Read the whole answerShow less
The manager is the messenger, not the fault. If no separate line reports that process dying, it was still alive and its executor was blocked — which is why the heartbeat timer never fired.
fixed in the threadOpen the thread
navigation2#2931AMCL localisation, ROS 2 (Foxy/Galactic)
AMCL crashes on map change with first_map_only=false — on Foxy almost every time.
The log points at
SIGSEGV in map_calc_range() inside libmap_lib.so — a stripped frame with no line, ten frames of tf2 internals below it.
What the engineer found
Two different mutexes guarded the same map: the map callback locked configuration_mutex_, the laser callback locked pf_mutex_ — so they excluded nothing. The fix merged both into one.
TrialONE said
Specifically, in `amcl_node.cpp`, the `laserReceived` callback (which calls `updateFilter` and eventually `map_calc_range`) must lock the mutex before accessing the map, and the map update callback must lock the same mutex before reassigning the map pointer.
Fixed by PR #2933, 'Added mutex to prevent SEGFAULT on map change in AMCL', merged 2022-05-05.Open the thread
navigation2#3480MPPI controller, ROS 2
controller_server segfaults in path_follow_critic when planning on the spot.
The log points at
A crash address inside the critic — nothing about who emptied the path it was reading.
What the engineer found
The critic ran on an empty path; the fix returns early in path_follow_critic.cpp when there is no data to compare against.
TrialONE said
The crash is a null-pointer dereference in `path_follow_critic.cpp:54` (the `o` function), but the root cause is a race condition in the `SimpleActionServer`'s async execution.
Fixed by PR #3484, merged 2023-03-16, backported.Open the thread
ros2_controllers#688joint_trajectory_controller, ros2_control
Segmentation fault when running the JTC action tests.
The log points at
A crash in assign_interface_from_point at line 355 — the line that received the bad index, not the configuration that made it bad.
What the engineer found
The controller was configured with fewer command interfaces than the hardcoded index assumed; the hardening landed in joint_trajectory_controller.cpp.
TrialONE said
The segmentation fault occurs because `joint_command_interface_` is accessed at index 3 without checking that the vector has at least 4 elements.
Fixed by PR #705, '[JTC] Re-enabling test, bugfixing and hardening', merged 2023-07-17.Open the thread
ardupilot#33204ArduSub, GPS blending
SITL crash during pre-arm with GPS blending enabled.
The log points at
The crash frame: AP_GPS::pre_arm_checks dereferencing a null driver.
What the engineer found
The maintainer guarded the CALLER instead — the arming path in ArduSub/AP_Arming_Sub.cpp. Our diagnosis named the crashing function and proposed the null check there: right mechanism, wrong owner.
TrialONE said
The crash is a null-pointer dereference at AP_GPS::pre_arm_checks() line 1843, which dereferences drivers[GPS_BLENDED_INSTANCE] (index 2) without a null check.
partial · Fixed by PR #33217 in ArduSub/AP_Arming_Sub.cpp.Open the thread

It prints what would have proved it wrong.

The bottom of a real report, verbatim. A tool that hides its own weak spots is not more accurate — only quieter.

5 of 8 unseen cases name the exact file the maintainer changed

Eight real incidents the engine had never touched — MoveIt, Nav2, ros2_control, ArduPilot — each with the customer's source tree checked out at the commit the reporter was running (the fix PR's base.sha, so the answer cannot be in the tree). Five diagnoses named the exact file the maintainer's fix changed; one correctly declared the fix unfindable from a four-line artifact; two missed, and we name them and why. On the 13 older reference cases the same build scores 12 of 13. Temperature 0, 3–4 cents and minutes per diagnosis. Measured 2026-08-29/30.

The score counts file paths, not words — a path like costmap_2d_publisher.cpp does not fall out of fluent prose. We rebuilt this benchmark after catching our own earlier one handing over source trees that already contained the fix (13 of 16 cases, up to nine years too new): every number measured that way was fiction, and every number above was measured after the repair. Where a cause is not derivable from what was recorded, saying so counts as the correct answer — inventing one does not.

4 of 4 checks that could have killed the diagnosis held.

DIAGNOSIS (supported, 4/4 checkable predictions held)

✓ HOLDS
/Sensor origin.*out of map bounds/
must appear · 4 matching lines
✓ HOLDS
/VoxelLayer::updateBounds/
must appear · 1 matching line
✓ HOLDS
/ObstacleLayer::updateBounds/
must NOT appear · 0 matching lines
✓ HOLDS
/bresenham3D/
must appear · 1 matching line

Written before looking. The report prints them whether they hold or not.

What it touched: search_log ×11 · compare_recordings ×1 · decode_number ×1 · list_nearby_recordings ×1 · log_vocabulary ×1. Never used: show_region, decode_errno — so nothing here rests on what those would have shown.

verbatim from output/reports/navigation2_2373.txt · navigation2#2373

Twice as often on the question that costs money.

Same 20 logs, same word lists, same model. Every case is a real failure from a public issue tracker where a maintainer eventually found the cause and wrote it down — where the timeline is recorded, they needed between two hours and 111 days.

4 : 0

binary recordings

ArduPilot .BIN, MCAP, HDF5. There is nothing to paste into a chat window — it scores zero, four times out of four.

6 : 3

the file and line to change

Twice as often. Naming a fault got cheap for everyone; finding where it lives did not.

16 : 14

naming the fault in a text log

Our narrowest margin, and we print it anyway — you should know where the gap is thin.

Text logs are 16 of the 20 cases because that is where public ground truth lives — nobody attaches a 400 MB bag to an issue.

One line, one file.

controller_manager/src/ros2_control_node.cpp

TrialONE's proposed repair for ros2_control#1905 — routed to a coding agent, domain software, flagged candidate: confirm before acting. A maintainer needed about two hours to find it.

ros2_control#1905

Nine fields. Every time.

The answer is not a report you then have to act on. It is a repair recipe in nine fixed fields — and the list of what it could not check.

1 / 9
symptom
what the machine did
2 / 9
causal chain
how it got there
3 / 9
condition
the measured values that make it true
4 / 9
change class
code · parameter · hardware
5 / 9
sites
file and line — proven or flagged as candidate
6 / 9
pattern
the reference pattern it matches
7 / 9
acceptance
the check that rejects a partial fix
8 / 9
blast radius
what else this touches
9 / 9
effort
what it costs to do

Reads what your robot already writes.

No SDK to add and nothing to rewrite. Point it at the files your stack produces today.

ROS 2 bags, .mcap and the live graph
crash logs, with your source tree
backtraces, down to the file
ros2_controlcontroller logs
.ulg flight logs
.BIN logs
datasets, v2 and v3
SocketCANcandump and the live bus

Names and logos belong to their owners. They say what TrialONE reads, not who endorses it.

Every claim, checked.

8 public threads where the log did not say what broke.

The controller intermittently commands motion nobody asked for.

Wi-Fi scanning breaks after a while; the board reports thermal sensor failures.

Restarting one process reproducibly crashes one, several, or all of the others.

controller_server and planner_server die with a segmentation fault at random.

AMCL crashes on map change with first_map_only=false — on Foxy almost every time.

controller_server segfaults in path_follow_critic when planning on the spot.

Segmentation fault when running the JTC action tests.

SITL crash during pre-arm with GPS blending enabled.

It prints what would have proved it wrong.

4 of 4 checks that could have killed the diagnosis held.

Twice as often on the question that costs money.

One line, one file.

Nine fields. Every time.

symptom

causal chain

condition

change class

sites

pattern

acceptance

blast radius

effort

Reads what your robot already writes.