Print

Print


I've observed the `xrdfs <host> xattr <path> get <attribute>` command segfaults, as per the example (tested on latest `master` commit):
```
$ xrdfs root://eospps.cern.ch:1094/ xattr /eos/opstest/dteam/file.test get xroot.cksum
Segmentation fault
```
Equivalent Gfal2 call works:
```
$ gfal-xattr root://eospps.cern.ch:1094//eos/opstest/dteam/file.test xroot.cksum
adler32 7e24b403
```

Stacktrace of the crash:
```
$ gdb --args /workspace/remote/xrootd/cmake-build/src/XrdCl/xrdfs root://eospps.cern.ch:1094/ xattr /eos/opstest/dteam/file.test get xroot.cksum
(gdb) bt
#0  std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffffd3f0, __str=<error reading variable: Cannot access memory at address 0x0>)
    at /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:173
#1  0x000000000042990c in XrdCl::XAttrStatus::XAttrStatus (this=0x7fffffffd3f0) at /workspace/remote/xrootd/src/./XrdCl/XrdClXRootDResponses.hh:290
#2  0x00000000004299ae in XrdCl::XAttr::XAttr (this=0x7fffffffd3f0) at /workspace/remote/xrootd/src/./XrdCl/XrdClXRootDResponses.hh:308
#3  0x0000000000425eac in DoXAttr (fs=0x643e00, env=0x642970, args=std::vector of length 4, capacity 4 = {...}) at /workspace/remote/xrootd/src/XrdCl/XrdClFS.cc:1688
#4  0x000000000043143c in XrdCl::FSExecutor::Execute (this=0x6428b0, args=std::vector of length 4, capacity 4 = {...}) at /workspace/remote/xrootd/src/XrdCl/XrdClFSExecutor.cc:100
#5  0x0000000000427a38 in ExecuteCommand (ex=0x6428b0, argc=4, argv=0x7fffffffdc08) at /workspace/remote/xrootd/src/XrdCl/XrdClFS.cc:1950
#6  0x00000000004283ce in ExecuteCommand (url=..., argc=4, argv=0x7fffffffdc08) at /workspace/remote/xrootd/src/XrdCl/XrdClFS.cc:2146
#7  0x0000000000428619 in main (argc=6, argv=0x7fffffffdbf8) at /workspace/remote/xrootd/src/XrdCl/XrdClFS.cc:2191
```

Logs around the crash:
```
$ XRD_LOGLEVEL=Debug xrdfs root://eospps.cern.ch:1094/ xattr /eos/opstest/dteam/file.test get xroot.cksum
...
[2021-01-27 16:46:15.526891 +0100][Debug  ][XRootDTransport   ] [eospps.cern.ch:1094.0] Sending authentication data
[2021-01-27 16:46:15.528885 +0100][Debug  ][XRootDTransport   ] [eospps.cern.ch:1094.0] Trying to authenticate using gsi
[2021-01-27 16:46:15.583897 +0100][Debug  ][XRootDTransport   ] [eospps.cern.ch:1094.0] Sending more authentication data for gsi
[2021-01-27 16:46:15.590991 +0100][Debug  ][XRootDTransport   ] [eospps.cern.ch:1094.0] Authenticated with gsi.
[2021-01-27 16:46:15.591065 +0100][Debug  ][PostMaster        ] [eospps.cern.ch:1094] Stream 0 connected.
[2021-01-27 16:46:15.591096 +0100][Debug  ][Utility           ] Monitor library name not set. No monitoring
[2021-01-27 16:46:15.591196 +0100][Debug  ][ExDbgMsg          ] [eospps.cern.ch:1094] Moving MsgHandler: 0x80abc0 (message: kXR_unknown (length: 43) ) from out-queu to in-queue.
[2021-01-27 16:46:15.591798 +0100][Debug  ][XRootD            ] [eospps.cern.ch:1094] Handling error while processing kXR_unknown (length: 43): [ERROR] Error response: invalid request code.
[2021-01-27 16:46:15.591860 +0100][Debug  ][ExDbgMsg          ] [eospps.cern.ch:1094] Calling MsgHandler: 0x80abc0 (message: kXR_unknown (length: 43) ) with status: [ERROR] Error response: invalid request code.
[2021-01-27 16:46:15.591942 +0100][Debug  ][ExDbgMsg          ] [eospps.cern.ch:1094] Destroying MsgHandler: 0x80abc0.
Segmentation fault
...
```

What I've noticed is that the client sends an `kXR_unknown` and the server responds with an error. More in-depth, [XrdClFS.DoXAttr(..):1687](https://github.com/xrootd/xrootd/blob/master/src/XrdCl/XrdClFS.cc#L1687) calls the `XrdClFileSystem.GetXAttr(..)` function, which at [line 1981](https://github.com/xrootd/xrootd/blob/master/src/XrdCl/XrdClFileSystem.cc#L1981) returns a status which is not successful. The next line of `XrdClFS.DoXAttr(..)` does not check the status and instead tries to construct the `XAttr` object from  `std::vector<XAttr> result`. As the vector is empty, the segfault is triggered.

-- 
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/1389

########################################################################
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