The challenge
An embedded Linux gateway repeatedly crashed while processing a multi-group schedule. Restarting the service did not help: the same configuration returned from the server and triggered the failure again. The investigation needed to preserve and reproduce that exact input.
The engineering
- Matched the affected application to its source and toolchain, then reproduced the triggering schedule conversion.
- Traced two interacting defects: repeated groups that were not adjacent, and incorrect ownership of shared JSON objects.
- Corrected both paths, built a matching gateway binary, and tested with the original failure-triggering input.
- Ported the repair forward while documenting the additional packaging and regression checks still needed for the newer branch.
What was verified
In the recorded validation window, the patched gateway processed the original schedule, opened its network listener, refreshed configuration, and sent heartbeats without another observed crash.
The observed result applies to the tested application and BSP combination. Newer-branch packaging and hardware regression remained separate follow-up work; the test was not a long-term reliability study.
The takeaway
Keep the original trigger and verify the repair against it. When a failure involves ownership, concurrency, or persistence, removing the symptom can leave another fault underneath.
This anonymized example draws on prior engineering work to illustrate our technical approach. It is not presented as a Tethrio Technologies client engagement.