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:

  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, 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":"@simonmichal in #482: Possible scenario:\r\n\r\n1. Client sends a request, the request was assigned with a SID.\r\n\r\n2. The request times-out, the SID goes to the set with timed-out SID.\r\n\r\n3. Due to bug #482, another request uses exactly the same SID to send \r\n a complitly unrelated request. So now our SID is in the timed-out \r\n set but also there exists a XRootDMsgHandler assigned to it !!!\r\n\r\n4. The response to the original request comes in. The AsyncSocketHandler\r\n creates a new message object, and afterwards it calls \r\n Stream::InstallIncHandler (XrdClAsyncSocketHandler.cc : 613). As a \r\n result:\r\n - the XRootDMsgHandler object takes ownership of the message \r\n object (XRootDMsgHandler::pResponse points to our message).\r\n - pSubStream[stream]-\u003einMsgHelper holds a pointer to the XRootDMsgHandler\r\n object\r\n\r\n5. Subsequently, the AsyncSocketHandler calls Stream::OnIncoming, which\r\n calls XRootDTransport::MessageReceived(), and in here the message \r\n object is deleted. Stream::OnIncomming returns without resetting the \r\n pSubStream[stream]-\u003einMsgHelper !!!\r\n\r\n6. Next time the AsyncSocketHandler::OnRead() will be called, and will\r\n ask for a handler (Stream::InstallIncHandler), it will get the \r\n XRootDMsgHandler that took ownership of the deleted message, because\r\n the pSubStream[stream]-\u003einMsgHelper was not reset. The response \r\n together with the XRootDMsgHandler will be submitted to the thread-pool.\r\n\r\n7. When the task in question gets executed the XRootDMsgHandler::Process\r\n will be called, and the pResponse (which points to the messages that\r\n has been created in 4.) will be destroyed. Hence, we get a double delete.\r\n\r\n@bbockelm : \r\n#482, which is the root of all evil in this scenario, has been fixed in 4.6.1,\r\nso could you check if you can reproduce the problem with RC1 and let me \r\nknow?\r\n\r\nThanks,\r\nMichal"}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/482#issuecomment-292581289"}}}

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