 |
 |
Hi Ulf, I compiled xrootd on CentOS 3.10.0-123.8.1.el7.x86_64 with all stack checking turned on. No problems were encountered. So, I suspect it is one of the plugins that you are using that is causing the problem. Could you provide your config file so I can see what plugins you are actually using? Andy P.S. Other people have reported similar problems in certain releases of CentOS for other daemons. Not clear who's problem that is. On Sat, 18 Oct 2014, Ulf Tigerstedt wrote: > On 18/10/14 05:18, Andrew Hanushevsky wrote: >> Hi Ulf, >> >> Well, we have not tried this combination. So, I wouldn't say this is >> indicative of something inherently wrong; especially since no other >> reports of this have occured for any OS that we support. I think that >> Lukasz may have a beta RH7 version now that hasn't made it to final >> distribution. So, he may be able to provide an RPM. Anyway, does this >> die right at startup or does it run for a while then crash? > > It runs for a while, which makes it so much harder to debug it. > > It also kills the cmsd with the same error message. > > (the messages are from /var/log/xrootd/xrootd.log and cmsd.log. > > I haven't set up the box, I just compiled the software and just happens to be > awake. > > I think I managed to change the settings to enable coredumps now, hopefully I > can get something out of it. > >> Andy >> >> On Sat, 18 Oct 2014, Ulf Tigerstedt wrote: >> >>> Our box is a bit unstable, with xrootd dying: >>> >>> >>> 141018 03:09:02 2391 Copr. 2004-2012 Stanford University, xrd version >>> v4.0.3 >>> *** stack smashing detected ***: /usr/bin/xrootd terminated >>> ======= Backtrace: ========= >>> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f0740eb58f7] >>> /lib64/libc.so.6(__fortify_fail+0x0)[0x7f0740eb58c0] >>> /lib64/libXrdUtils.so.2(+0x2a124)[0x7f0741fda124] >>> /lib64/libXrdUtils.so.2(_ZN12XrdSysLogger8zHandlerEv+0xa8)[0x7f0741fdae18] >>> >>> /lib64/libXrdUtils.so.2(_Z14XrdSysLoggerRTPv+0x1a)[0x7f0741fdb15a] >>> /lib64/libXrdUtils.so.2(XrdSysThread_Xeq+0x37)[0x7f0741fd3107] >>> /lib64/libpthread.so.0(+0x7df3)[0x7f0741b97df3] >>> /lib64/libc.so.6(clone+0x6d)[0x7f0740e9e01d] >>> ======= Memory map: ======== >>> >>> >>> soo.. xrootd is having buffer overflows? >>> >>> xrootd is from epel7, the FAX stuff I compiled myself from srpms >>> provided by the FAX team. >>> Does anyone have suggestions what to do? Luckily it sees a RO mount of >>> our dCache, so it can't make that big of a mess even if someone cracks >>> it. >>> >>> >>> -- >>> Ulf Tigerstedt || CSC Oy || NDGF >>> Computing Environments group >>> (NGI_FI and NGI_NDGF) deputy manager >>> GSM +358503818558 || +35894572279 >>> Keilaranta 14 || Espoo || Finland >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>> >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > > > -- > Ulf Tigerstedt || CSC Oy || NDGF > Computing Environments group > (NGI_FI and NGI_NDGF) deputy manager > GSM +358503818558 || +35894572279 > Keilaranta 14 || Espoo || Finland > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1