 |
 |
Congrats for figuring this out, it's a pretty nasty one! Your patch definitely looks like a step in the right direction, however you did not handle the situation when the recovery open comes back successful. In this case you need to: 1. Send a `kXR_close`, otherwise you're leaking file handles, which, if there is enough clients behaving like this, may have adverse consequences for the server. Yes, `File`'s destructor actually sends a `kXR_close`, but it's blocking and, since the destruction succeeded, it means that the `close` returned an error before the recovery open returned anything. 2. Since the user deleted the `File` object, he does not expect any of his callbacks to come back any more and may delete them. If there are still some requests in the recovery queue, they are likely to be processed and call the dangling pointers. You need to make sure that no recovery is attempted when the `File` object has been deleted, but the recovery open may still be successful. --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/289#issuecomment-143591969 ######################################################################## 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