Well, see above, it's the same. You can also login to xcache-00.t2.ucsd.edu and look at the core in /core/cores ... if you still remember how to get there ;) Dumping memory at the address pResponse points to, I noticed in three cores string "[ERROR] Socket error", e.g.: ``` (gdb) x/48sb pResponse 0x7f7a84087e30: "\260\372\024\204z\177" 0x7f7a84087e37: "" 0x7f7a84087e38: "\024" 0x7f7a84087e3a: "" 0x7f7a84087e3b: "" 0x7f7a84087e3c: "" 0x7f7a84087e3d: "" 0x7f7a84087e3e: "" 0x7f7a84087e3f: "" 0x7f7a84087e40: "\377\377\377\377" 0x7f7a84087e45: "" 0x7f7a84087e46: "" 0x7f7a84087e47: "" 0x7f7a84087e48: "[ERROR] Socket error" 0x7f7a84087e5d: "\177" ... ``` Clearly, the pResponse has already been deallocated ... and apparently there was a socket error happening around that time. Do you know of a way to nuke a specific socket? I could then run cache in valgrind and see what happens. There is also this in Michal's list of things added for 4.9.1 (which worries me a bit at this point :) ): b4307a8 [XrdCl] Remove unnecessary ref counting from MsgHandler 74ae6df [XrdCl] Remove unnecessary mutex. -- 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/937#issuecomment-475509867 ######################################################################## 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