-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
case clause error when TLS handshake is closed abruptly #7506
Comments
This seems strange. It would mean that inet:getopts would return {ok, []} which it should not unless you give it an empty list as input. I suppose you do not have some wrapper transport module? I could be helpful if you could trace tls_socket:getopts/3 when it happens if you have that possibility. |
I just did a thorough read of the code in So it should be possible that |
Thanks everyone for taking a look. I thought it seemed strange when we got that stack trace. If I ever have a clue how to reproduce it of course I will follow up. |
See #7522 |
…turn/GH-7506/OTP-18697 ssl: Handle that inet:getopts may return {ok, []}
I apologize that this report is not up to my usual standard where I provide a reliable means to reproduce it.
Describe the bug
Based on logs provided by a RabbitMQ customer, it appears there is something creating a TCP connection that initiates a TLS handshake but then closes the socket, producing this log message:
In addition, sometimes this leads to a case clause error as shown in the attached log file:
case-clause-log.txt
Code: https://github.com/erlang/otp/blob/OTP-25.0.4/lib/ssl/src/ssl_gen_statem.erl#L1964-L1969
I am assuming this is due to the state moving to "closed" but RabbitMQ trying to still get socket options. I'm wondering if the
{ok, []}
case should be handled inssl_gen_statem:get_socket_opts/6
.To Reproduce
I have not yet been able to reproduce this.
Affected versions
25.0.4
Additional context
The main reason we're concerned about this crash is that this customer also experiences high memory use by the
ssl_gen_statem
process - frequently over 100MiB. I'm wondering if this case clause issue prevents data from being garbage collected.The text was updated successfully, but these errors were encountered: