 |
 |
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 or view it on GitHub: 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