Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Uninitialised value used during prepare lib handling with 4.10rc4 #1013

Closed
smithdh opened this issue Jun 27, 2019 · 2 comments
Closed

Uninitialised value used during prepare lib handling with 4.10rc4 #1013

smithdh opened this issue Jun 27, 2019 · 2 comments

Comments

@smithdh
Copy link
Contributor

smithdh commented Jun 27, 2019 •
edited

Hi,

In a test with an xrootd server configured using the "/etc/xrootd/xrootd-standalone.cfg" configuration valgrind reports that an uninitialised value is used.

The environment is a centos 7 machine, including packages from this testing repo: http://xrootd.org/binaries/testing/slc/7/$basearch or http://xrootd.cern.ch/sw/repos/testing/slc/7/$basearch:

rpm -qa | grep -i xroot

xrootd-4.10.0-0.rc4.el7.x86_64
xrootd-server-4.10.0-0.rc4.el7.x86_64
xrootd-libs-4.10.0-0.rc4.el7.x86_64
xrootd-server-libs-4.10.0-0.rc4.el7.x86_64
xrootd-client-devel-4.10.0-0.rc4.el7.x86_64
xrootd-devel-4.10.0-0.rc4.el7.x86_64
xrootd-client-libs-4.10.0-0.rc4.el7.x86_64
xrootd-debuginfo-4.10.0-0.rc4.el7.x86_64
xrootd-client-4.10.0-0.rc4.el7.x86_64
xrootd-selinux-4.10.0-0.rc4.el7.noarch

Running with valgrind:

valgrind --tool=memcheck --num-callers=40 --log-file=/tmp/vg-10 /usr/bin/xrootd -l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-standalone.cfg -k fifo -s /var/run/xrootd/xrootd-standalone.pid -n standalone

and issuing this against the server:

xrdfs root:// prepare -f /

and then sending the xrootd a TERM signal gives this valgrind report:

==13849== Memcheck, a memory error detector
==13849== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13849== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==13849== Command: /usr/bin/xrootd -l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-standalone.cfg -k fifo -s /var/run/xrootd/xrootd-standalone.pid -n standalone
==13849== Parent PID: 32648
==13849==
==13849== Conditional jump or move depends on uninitialised value(s)
==13849== at 0x4EA0C50: XrdOfs::Configure(XrdSysError&, XrdOucEnv*) (XrdOfsConfig.cc:274)
==13849== by 0x4E9C9E1: XrdSfsGetDefaultFileSystem(XrdSfsFileSystem*, XrdSysLogger*, char const*, XrdOucEnv*) (XrdOfsFS.cc:69)
==13849== by 0x4E79998: XrdXrootdProtocol::Configure(char*, XrdProtocol_Config*) (XrdXrootdConfig.cc:282)
==13849== by 0x4E82722: XrdgetProtocol (XrdXrootdProtocol.cc:165)
==13849== by 0x40B3C1: XrdProtLoad::Load(char const*, char const*, char*, XrdProtocol_Config*) (XrdProtLoad.cc:101)
==13849== by 0x40705D: XrdConfig::Setup(char*) (XrdConfig.cc:1042)
==13849== by 0x40A341: XrdConfig::Configure(int, char**) (XrdConfig.cc:522)
==13849== by 0x4061C3: main (XrdMain.cc:179)
==13849==
==13849== Thread 5:
==13849== Conditional jump or move depends on uninitialised value(s)
==13849== at 0x4E9943A: XrdOfs::prepare(XrdSfsPrep&, XrdOucErrInfo&, XrdSecEntity const*) (XrdOfs.cc:1847)
==13849== by 0x4E91246: XrdXrootdProtocol::do_Prepare(bool) (XrdXrootdXeq.cc:1706)
==13849== by 0x5175928: XrdLink::DoIt() (XrdLink.cc:441)
==13849== by 0x5178CDE: XrdScheduler::Run() (XrdScheduler.cc:357)
==13849== by 0x5178E28: XrdStartWorking(void*) (XrdScheduler.cc:87)
==13849== by 0x513E9A6: XrdSysThread_Xeq (XrdSysPthread.cc:86)
==13849== by 0x55AFDD4: start_thread (in /usr/lib64/libpthread-2.17.so)
==13849== by 0x62E8EAC: clone (in /usr/lib64/libc-2.17.so)
==13849==
==13849==
==13849== Process terminating with default action of signal 15 (SIGTERM)
==13849== at 0x55B5ADB: do_futex_wait.constprop.1 (in /usr/lib64/libpthread-2.17.so)
==13849== by 0x55B5B6E: __new_sem_wait_slow.constprop.0 (in /usr/lib64/libpthread-2.17.so)
==13849== by 0x55B5C0A: sem_wait@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.17.so)
==13849== by 0x40C1F7: UnknownInlinedFun (XrdSysPthread.hh:419)
==13849== by 0x40C1F7: mainAccept(void*) (XrdMain.cc:130)
==13849== by 0x406338: main (XrdMain.cc:211)
==13849==
==13849== HEAP SUMMARY:
==13849== in use at exit: 117,844 bytes in 163 blocks
==13849== total heap usage: 391 allocs, 228 frees, 159,819 bytes allocated
==13849==
==13849== LEAK SUMMARY:
==13849== definitely lost: 574 bytes in 16 blocks
==13849== indirectly lost: 0 bytes in 0 blocks
==13849== possibly lost: 22,491 bytes in 21 blocks
==13849== still reachable: 94,779 bytes in 126 blocks
==13849== of which reachable via heuristic:
==13849== newarray : 7,312 bytes in 2 blocks
==13849== suppressed: 0 bytes in 0 blocks
==13849== Rerun with --leak-check=full to see details of leaked memory
==13849==
==13849== For counts of detected and suppressed errors, rerun with: -v
==13849== Use --track-origins=yes to see where uninitialised values come from
==13849== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

I believe this is due to a missing initialiser in XrdOfsConfigPI::XrdOfsConfigPI for the member prpPI. The uninitialised value would be used in case there is no ofs.preplib directive in the configuration file.

In the case above xrootd seems to work without problem. However as is often the case with uninitialised values, it may work fine, until it does not. (e.g. when using a configuration which is different, in apparently unrelated ways, or the glibc version changes, etc etc.). The XrdOfsConfigPI constructor initialises other member pointer types to zero, it may be safer to also initialise prpPI in a similar way.

(This valgrind check was done because a crash was seen, in an xrootd server environment which is less controlled. i.e. with non-standard plugins, mixing of versions etc. But for clarity it seems best to report this issue separately, against a more standard environment).

Thanks a lot,
David
@abh3
Copy link
Member

abh3 commented Jun 27, 2019 via email

@smithdh
Copy link
Contributor Author

smithdh commented Jun 28, 2019

Hi. Great, thanks Andy.
I'll close the ticket now.
David

@smithdh smithdh closed this as completed Jun 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@abh3 @smithdh