 |
 |
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 calls the XrdClFileSystem.GetXAttr(..) function, which at line 1981 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, 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