Hmmm, I thought sids put in the timeout set couldn't be reallocated
because ones doesn't know whn the response will come back. Of course, they
are lost if no responds comes back. However, they are reclaimed when the
connection closes (the server cancels all requests when that happons). So,
the big question here is how did the sid get reallocated?
Andy
On Fri, 7 Apr 2017, simonmichal wrote:
> Possible scenario:
>
> 1. Client sends a request, the request was assigned with a SID.
>
> 2. The request times-out, the SID goes to the set with timed-out SID.
>
> 3. Due to bug #482, another request uses exactly the same SID to send
> a complitly unrelated request. So now our SID is in the timed-out
> set but also there exists a XRootDMsgHandler assigned to it !!!
>
> 4. The response to the original request comes in. The AsyncSocketHandler
> creates a new message object, and afterwards it calls
> Stream::InstallIncHandler (XrdClAsyncSocketHandler.cc : 613). As a
> result:
> - the XRootDMsgHandler object takes ownership of the message
> object (XRootDMsgHandler::pResponse points to our message).
> - pSubStream[stream]->inMsgHelper holds a pointer to the XRootDMsgHandler
> object
>
> 5. Subsequently, the AsyncSocketHandler calls Stream::OnIncoming, which
> calls XRootDTransport::MessageReceived(), and in here the message
> object is deleted. Stream::OnIncomming returns without resetting the
> pSubStream[stream]->inMsgHelper !!!
>
> 6. Next time the AsyncSocketHandler::OnRead() will be called, and will
> ask for a handler (Stream::InstallIncHandler), it will get the
> XRootDMsgHandler that took ownership of the deleted message, because
> the pSubStream[stream]->inMsgHelper was not reset. The response
> together with the XRootDMsgHandler will be submitted to the thread-pool.
>
> 7. When the task in question gets executed the XRootDMsgHandler::Process
> will be called, and the pResponse (which points to the messages that
> has been created in 4.) will be destroyed. Hence, we get a double delete.
>
> @bbockelm :
> #482, which is the root of all evil in this scenario, has been fixed in 4.6.1,
> so could you check if you can reproduce the problem with RC1 and let me
> know?
>
> Thanks,
> Michal
>
> --
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/482#issuecomment-292581289
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@abh3 in #482: Hmmm, I thought sids put in the timeout set couldn't be reallocated \nbecause ones doesn't know whn the response will come back. Of course, they \nare lost if no responds comes back. However, they are reclaimed when the \nconnection closes (the server cancels all requests when that happons). So, \nthe big question here is how did the sid get reallocated?\n\nAndy\n\nOn Fri, 7 Apr 2017, simonmichal wrote:\n\n\u003e Possible scenario:\n\u003e\n\u003e 1. Client sends a request, the request was assigned with a SID.\n\u003e\n\u003e 2. The request times-out, the SID goes to the set with timed-out SID.\n\u003e\n\u003e 3. Due to bug #482, another request uses exactly the same SID to send\n\u003e a complitly unrelated request. So now our SID is in the timed-out\n\u003e set but also there exists a XRootDMsgHandler assigned to it !!!\n\u003e\n\u003e 4. The response to the original request comes in. The AsyncSocketHandler\n\u003e creates a new message object, and afterwards it calls\n\u003e Stream::InstallIncHandler (XrdClAsyncSocketHandler.cc : 613). As a\n\u003e result:\n\u003e - the XRootDMsgHandler object takes ownership of the message\n\u003e object (XRootDMsgHandler::pResponse points to our message).\n\u003e - pSubStream[stream]-\u003einMsgHelper holds a pointer to the XRootDMsgHandler\n\u003e object\n\u003e\n\u003e 5. Subsequently, the AsyncSocketHandler calls Stream::OnIncoming, which\n\u003e calls XRootDTransport::MessageReceived(), and in here the message\n\u003e object is deleted. Stream::OnIncomming returns without resetting the\n\u003e pSubStream[stream]-\u003einMsgHelper !!!\n\u003e\n\u003e 6. Next time the AsyncSocketHandler::OnRead() will be called, and will\n\u003e ask for a handler (Stream::InstallIncHandler), it will get the\n\u003e XRootDMsgHandler that took ownership of the deleted message, because\n\u003e the pSubStream[stream]-\u003einMsgHelper was not reset. The response\n\u003e together with the XRootDMsgHandler will be submitted to the thread-pool.\n\u003e\n\u003e 7. When the task in question gets executed the XRootDMsgHandler::Process\n\u003e will be called, and the pResponse (which points to the messages that\n\u003e has been created in 4.) will be destroyed. Hence, we get a double delete.\n\u003e\n\u003e @bbockelm :\n\u003e #482, which is the root of all evil in this scenario, has been fixed in 4.6.1,\n\u003e so could you check if you can reproduce the problem with RC1 and let me\n\u003e know?\n\u003e\n\u003e Thanks,\n\u003e Michal\n\u003e\n\u003e -- \n\u003e You are receiving this because you are subscribed to this thread.\n\u003e Reply to this email directly or view it on GitHub:\n\u003e https://github.com/xrootd/xrootd/issues/482#issuecomment-292581289\n"}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/482#issuecomment-292609011"}}}
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1