Untethering Core Dump Fixed?

[dev2production]

Hello, I noticed the latest release (1.46.7) has a bug fix to "Prevent an untethered subscription re-joining the stream at an old position.". Would this bug fix potentially solve a core dump that may occur with untethered subscriptions? I was running a few tests against 1.46.4 on various OSes with untethered subscriptions and the test application would sometimes crash with a core dump. Unfortunately, I cannot reproduce this scenario all the time.

[vyazelenko]

@dev2production In order to segfault Aeron process with a slow subscriber the following conditions must be true:

• A slow subscriber that cannot keep up with the publisher.
• Subscriber can disconnect:
  • There are other subscribers to the same stream.
  • The subscriber is running with tether=false or it is a multicast/MDC channel with non-min flow control used.
• Subscriber stalls in the Subscription#poll/Image#poll call until an Image goes unavailable (i.e. UnavailableImageHandler#onUnavailableImage is called) and stays blocked for at least aeron.client.resource.linger.duration (3 seconds by default) after this event, i.e. the ClientConductor thread will free the underlying log buffer.
• Poll is invoked with fragmentLimit > 1 and it is not the last fragment to be read.
• There are more frames in the active term buffer, i.e. reading the current fragment does not reach the end of the term buffer.

If all of the above are true then an attempt to read the next frame will segfault the JVM as the read will be performed from the log buffer that was freed.

[dev2production]

@vyazelenko Thank you very much for the detailed answer. A quick follow-up question; are you suggesting the segfault mentioned can still happen in the latest version (1.46.7) if all those conditions are true?

[vyazelenko]

@dev2production What I described above will segfault JVM when using Java media driver in any Aeron version. This issue needs to be addressed in the application, i.e. ultimately application should not take forever during a FragmentHandler#onFragment call. Tactically breaking any of the above conditions will also work (e.g. using fragmentLimit == 1).

[vyazelenko]

@dev2production I've pushed a change (https://github.com/real-logic/aeron/commit/ede0c033caaebdbbc5322a4900402b72cd0f8632) that would prevent a segfault if FragmentHandler blocks for a long time.

[dev2production]

@vyazelenko Fantastic. Really appreciate this change.