fix(cmrpc): release session when resend exhaustion aborts the AR - #601
Open
acrews42 wants to merge 1 commit into
Open
fix(cmrpc): release session when resend exhaustion aborts the AR#601acrews42 wants to merge 1 commit into
acrews42 wants to merge 1 commit into
Conversation
When pf_cmrpc_send_with_timeout exhausts its resend counter — a CControl request that never got a response, or a fragment that timed out — it aborts the AR (and, in the CControl branch, closes the socket) but never calls pf_session_release. The session stays in_use forever. With PF_MAX_SESSION = 2 * PNET_MAX_AR + 1 (three sessions in the default single-AR configuration), a handful of unanswered CControl requests permanently exhausts the pool. From then on the device logs "CMRPC: Out of session resources for incoming frame" for every incoming RPC frame: new Connects are still accepted (they reuse the recovered connect session) but record writes and PrmEnd stall until the controller's RPC timeout, and the AR eventually aborts with a CMSM startup timeout. The device is wedged until restart. Reproduced with a PROFINET controller repeatedly connecting/aborting against p-net sample devices: before this change a device wedged after ~3 unanswered CControls; after it, 3 consecutive full reconnect cycles across 32 simulated devices completed with flat establish times and zero session-exhaustion errors. Release the session in both exhaustion branches, after the AR abort. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
After a few AR churn cycles (controller connects, then aborts or disappears without answering the device's CControl/ApplicationReady request), a p-net device starts logging
for every incoming RPC frame and never recovers. New Connects are still accepted, but record writes and PrmEnd stall until the controller's RPC timeout, and the AR then aborts with
CMSM: Timeout for communication start up(0xFD/0x06). The device is effectively wedged until restart. A stale scheduler handle from the leaked session also producesSCHEDULER: Invalid value 0 for timeout "(null)". No removal.Root cause
In
pf_cmrpc_send_with_timeout, whenresend_counteris exhausted:from_me == truebranch (CControl request, no response) aborts the AR and closes the socket, but never callspf_session_release;The session stays
in_useforever. WithPF_MAX_SESSION = 2 * PNET_MAX_AR + 1— three sessions in the default single-AR configuration — a handful of unanswered CControls exhausts the pool permanently.Fix
Call
pf_session_releasein both exhaustion branches, after the AR abort (mirroring the release the normal completion paths perform).Testing
Reproduced with a PROFINET controller performing repeated connect/abort cycles against 32 p-net-based simulated devices (Linux, default options):
Happy to sign a CLA or rework the patch to your conventions if needed — this is also offered under the project's GPLv3 terms for the dual-license arrangement at your discretion.