search

tcp-acceleration-service / tas

TAS is a drop-in highly CPU efficient and scalable TCP acceleration service.
https://tcp-acceleration-service.github.io/
Other
82 stars 43 forks source link

Assertion failure in uxsocket_receive #11

Closed ash995 closed 3 years ago

ash995 commented 3 years ago

The following assertion inside the uxsocket_receive function fails

assert(cmsg->cmsg_len == CMSG_LEN(sizeof(int)));

cmsg->cmsg_len is set to 8, whereas CMSG_LEN(sizeof(int)) returns 20. Any idea as to why this may be happening?

FreakyPenguin commented 3 years ago

Sorry for the delay. Off the top of my head I don't have an idea why this might happen. Is anything else going wrong before that? What are you doing to trigger this?

The message received there is sent from flextcp_kernel_newctx in lib/tas/kernel.c. So as a first step I would check the control message size there. Also check the .msg_controllen fields on both ends.

ash995 commented 3 years ago

Value of .msg_controllen field on both sides is 24. cmsg->cmsg_len right before sending is 20, but when it's received the value of cmsg->cmsg_len changes to 24.

ash995 commented 3 years ago

The recvmsg before the assertion fails as well, and returns -1. The cause of the failure is "Bad Address".

FreakyPenguin commented 3 years ago

Ah that would at least explain the unexpected values of cmsg_len. Not quite sure where the bad address for recvmsg would be coming from. Maybe set a breakpoint there and have a look at what pointers might be bad there (just looking at the code I really don't see anything...). Or maybe strace would also show this.

(I'll commit a fix to check the recvmsg result before checking the control data to avoid the initial confusion)

ash995 commented 3 years ago

req_rx was not getting initialized to 0 for some reason and was getting initialized by some garbage value. As soon as I set the value of req_rx to 0 while setting up struct application, the issue was fixed.