So, it's apparently due to flaky error recovery in XrdTpcStream.cc which causes it to go into a loop when it gets an error on write() and mismanage the buffers causing random destruction of memory. I still don't understand what it's trying to do but I identified at least three suspect cases that would cause this problem. So, while I look at it please look at it as well.
XrdTpcStream.hh:82 (this snippet makes no sense as a -1 is an error condition and the cast is suspicious)
int retval = stream.Write(m_offset, &m_buffer[0], size_desired, force);
if (retval < 0 && (static_cast<size_t>(retval) != size_desired)) {
return -1;
}
XrdTpcStream.cc:85 This where an error is supposedly handled. The problem there is no return and the code false into other code that thinks everything went fine and continues trying to write. The way the code is structured, an infinite write loop/buffer expansion results.

XrdTpcStream.cc:112 Apparent missing else after a write failure which ignores the failure and attempts to continue writing with the same results as above.

It's obviously all wrong but since there is no guidance on what should happen when an error occurs a proper fix is somewhat elusive. I suppose I can try just doing the most obvious fix and see if it still works or not.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

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