A Connection could not be closed before it is scheduled #19
Comments
|
Actually the problem is with the parser. Firstly, Means that there are no trailing CRLF at the end of Accept header and the whole request. Need to check with tcpdump whether wget sends the reuest and two CRLF trailers in separate TCP segments. Next suspicious part is When the parser is at begin of Accept header it goes to Req_HdrOther state which parses headers which we don't process in special maner (like we do this for Conten-Length for example). The problem is considers that the header has 62 charactes and that's not correct. Lastly,
|
|
I didn't pull the commit to my current branch, I'll test it later on master. |
|
Yes, agree. Please fix the parser (because it's easy for you to reproduce the issue) and assign the issue with updated Oops message to me. Or you always can debug the connection bug as well ;) |
vdmit11
added a commit
that referenced
this issue
Sep 22, 2014
The commit fixes closing a connection at a point when no TfwSession is yet established. Changes: 1. tfw_connection_free() now releases a TfwSession and a peer TfwConnection only if they exist. 2. tfw_connection_send_srv() doesn't close the connection by itself. Instead, it returns an error code which is propagated up to Synchronous Sockets, and the connection is closed from ss_do_close(). That is done to avoid a condition where the connection is referenced by SS after it is closed (and free()'d) in tfw_connection_send_srv(). 3. tfw_sess_conn() and tfw_connection_peer() now check for existence of session and connection objects and return NULL if they don't exist. 4. tfw_http_conn_destruct() frees a HTTP request attached to the message only if it exists. That is done to avoid another NULL pointer dereference that occurs because the requests are pipelined now, and this "current" request may be already pipelined and set to NULL when the destructor is called. 5. tfw_http_req_process() doesn't free a HTTP request anymore. It is done from a destructor called by ss_do_close() when tfw_http_req_process() returns TFW_BLOCK. 6. tfw_session_free() now releases all pipelined HTTP requests stored in the session's queue.
|
Alexander, please review. The HTTP parser seems to be fine now. The original Oops message was obtained on a version branched before 021e6a8. |
|
Fixed long time ago, see: 1cd52cf. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A NULL pointer dereference occurs when you connect to the Tempesta FW and close the TCP connection (send FIN from client) when the HTTP request is not yet parsed.
Scenario:
Actually my wget hangs after this, so I'm just hitting Ctrl+C and it sends FIN to the Tempesta server.
Result:
Actually the NULL pointer happens in an inlined function, so the full stack trace would look like:
The
tfw_connection_peer()tries to find a server connection for the given client connection. But the problem is there is no server yet associated with the client because the message is not scheduled yet at this point (HTTP parser is not finished yet). So thesess->srvis NULL.The server is obtained only to make
peer_conn->sess = NULL;intfw_connection_free(). If no session is yet established, then the field should already be NULL, so I think it may be fixed by simple NULL checks here.The text was updated successfully, but these errors were encountered: