-
Notifications
You must be signed in to change notification settings - Fork 103
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
sk->sk_destruct() is not being called when connection is closed #46
Comments
With the way Synchronous Sockets are implemented now, we never reach Right now we do a forceful "non-sleeping" socket close at By the way, calling |
An attempt to fix the issue was done in #59 |
It seems we ever have the problem in simple scenario on normal connection closing after successful data transfer in proxy mode:
|
This is probably wrong place for this trace. I believe it belongs to #60. The fix to the problem is presented there as well. |
Alexey, please check whether we still have the issue with recent changes in TCP_CLOSE handling, |
After commit 2cf2333 Tempesta throws many
|
The core issue here is a missing |
In some cases sock_put() was not called. Because of that, some sockets were not closed properly: sk->sk_destruct() was not called.
Release a hold on a socket when closing it. (#46)
Fixed with pull request 6a97572 |
It seems the issue is still not fixed and was just masked by 6a97572 . Issues #119 and #60 are relating. After the last commit (47d82a1) I got exactly the same warnings under the same test:
|
#8 relates to the issue. |
Scenario:
wget http://localhost
- should pass and give youindex.html
wget http://locslhost
- crashesThat happens because when the connection to nginx is closed, no
sk->sk_destruct()
is called.We put
tfw_destroy_server()
tosk->sk_destruct()
, so when the connection is closed, the server is not deleted from the load-balancing scheduler as it should be, and you get a NULL pointer dereference when you try to acess its connection.Generally, the problem is wider than the fact that
tfw_destroy_server()
is not invoked.Original socket destructor (usually
inet_release()
) is not invoked as well, so we likely have some memory leak here.A notable thing that when you call
sock_release()
, thesk->sk_destruct()
is invoked as it should be.We need to understand why
sk->sk_destruct()
is not invoked when a TCP connection is closed, but is invoked when you dosock_release()
.The text was updated successfully, but these errors were encountered: