michele-tramonti opened a new pull request, #2543: URL: https://github.com/apache/plc4x/pull/2543
## Summary Second direct-memory leak I noticed while auditing #2248 (and its fix #2542). Same family of bug, different code path. `S7ProtocolLogic.decodeEventSubscriptionResponse()` allocates two direct `ByteBuf`s when handling `S7PayloadUserDataItemCpuFunctionAlarmQueryResponse`: \`\`\`java ByteBuf buffer = Unpooled.directBuffer(items.getItems().length * 2); ByteBuf rxBuffer = Unpooled.directBuffer(items.getItems().length * 2); \`\`\` They are populated, then drained via \`ByteBufUtil.getBytes(rxBuffer)\` (which copies the bytes into a Java array) and the method returns. Neither buffer is ever \`release()\`d. \`ByteBufUtil.getBytes\` does not own the buffer and does not release it. On a PLC that emits alarms regularly, every alarm event leaks two direct buffers. On long-running applications this slowly exhausts \`MaxDirectMemorySize\` and triggers \`OutOfMemoryError: Cannot reserve N bytes of direct buffer memory\` — the same symptom as #2248, different root cause. ## Fix Wrap the existing logic in a `try/finally` so both buffers are released on every path, including when the inner parsing block (or any of the `loopFuture.get()` calls) propagates an exception. No change in behaviour or wire format — the buffers are local to the method and only used for reassembly before the bytes are copied out via `ByteBufUtil.getBytes`. ## Test plan - [x] `mvn -pl :plc4j-driver-s7 -P with-java test` passes -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
