Skip to content
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

Fix possible memory leak on TLS handshake failure #796

Merged
merged 1 commit into from
Jan 3, 2023

Conversation

JelteF
Copy link
Member

@JelteF JelteF commented Dec 23, 2022

On an unrelated PR a memory leak was reported by CI on a TLS test.

==11838== VALGRIND-ERROR-BEGIN
==11838== 71,890 (112 direct, 71,778 indirect) bytes in 1 blocks are definitely lost in loss record 178 of 178
==11838==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11838==    by 0x15B06E: tls_new (tls.c:240)
==11838==    by 0x16210B: tls_server_conn (tls_server.c:47)
==11838==    by 0x16248E: tls_accept_fds (tls_server.c:141)
==11838==    by 0x1380EB: sbuf_tls_accept (sbuf.c:1127)
==11838==    by 0x11E15A: handle_client_startup (client.c:729)
==11838==    by 0x11EF17: client_proto (client.c:1041)
==11838==    by 0x136069: sbuf_call_proto (sbuf.c:390)
==11838==    by 0x136B58: sbuf_process_pending (sbuf.c:583)
==11838==    by 0x13722C: sbuf_main_loop (sbuf.c:763)
==11838==    by 0x134FAB: sbuf_accept (sbuf.c:137)
==11838==    by 0x12D220: accept_client (objects.c:1540)
==11838==
==11838== VALGRIND-ERROR-END

Source: https://cirrus-ci.com/task/5909005202096128?logs=test#L91

When running the same test multiple times locally on my own machine this
reproduced ~100 runs. After adding some logging the reason turned out to
be that we were not always handling errors from handle_tls_handshake.

This PR fixes that by handling handshake errors in all places that we
call handle_tls_handshake. I confirmed this fixed the issue by running
the originally failing test 1000 times with valgrind and all runs passed
now.

On an unrelated PR a memory leak was reported by CI on a TLS test.
```
==11838== VALGRIND-ERROR-BEGIN
==11838== 71,890 (112 direct, 71,778 indirect) bytes in 1 blocks are definitely lost in loss record 178 of 178
==11838==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11838==    by 0x15B06E: tls_new (tls.c:240)
==11838==    by 0x16210B: tls_server_conn (tls_server.c:47)
==11838==    by 0x16248E: tls_accept_fds (tls_server.c:141)
==11838==    by 0x1380EB: sbuf_tls_accept (sbuf.c:1127)
==11838==    by 0x11E15A: handle_client_startup (client.c:729)
==11838==    by 0x11EF17: client_proto (client.c:1041)
==11838==    by 0x136069: sbuf_call_proto (sbuf.c:390)
==11838==    by 0x136B58: sbuf_process_pending (sbuf.c:583)
==11838==    by 0x13722C: sbuf_main_loop (sbuf.c:763)
==11838==    by 0x134FAB: sbuf_accept (sbuf.c:137)
==11838==    by 0x12D220: accept_client (objects.c:1540)
==11838==
==11838== VALGRIND-ERROR-END
```
Source: https://cirrus-ci.com/task/5909005202096128?logs=test#L91

When running the same test multiple times locally on my own machine this
reproduced ~100 runs. After adding some logging the reason turned out to
be that we were not always handling errors from `handle_tls_handshake`.

This PR fixes that by handling handshake errors in all places that we
call `handle_tls_handshake`. I confirmed this fixed the issue by running
the originally failing test 1000 times with valgrind and all runs passed
now.
Copy link
Member

@eulerto eulerto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. LGTM.

@JelteF JelteF merged commit 11a5bbc into master Jan 3, 2023
@JelteF JelteF deleted the fix-memory-leak-on-tls-handshake-failure branch January 3, 2023 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants