Print

Print


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