Hi Sergey and David,
Are you in the position to test 5-18-00-patches and tell us if it
works better?
The branch should have already all the fixes that we thought
necessary. If that is OK for you there
will be no problem in tagging 5.18/00e .
Cheers, Gerri
PS: I can make binaries for a couple of platforms if that can help
in testing; just let me know the
platforms/OS/compiler, i.e. which of the config strings you
use (e.g. 'slc4_ia32_gcc34').
Sergey Panitkin wrote:
> Hi Fabrizio,
>
> I would like to add to Andreas' comment about root 5.18.
> Latest production release of Atlas software- which is intended for
> data taking- is based on version 5.18. That's just the nature of long
> development cycle.
> From our point of view, a new, patched version of 5.18(e?) with xrootd
> client fixes is necessary.
>
> Cheers,
> Sergey
>
> Fabrizio Furano wrote:
>> [bounced to xrootd-l]
>>
>> Hi Andreas,
>>
>> yes, afaik it's fixed, and the tests performed around report that
>> it is ok.
>> 5.18 is very old now, and I would recommend that users switch to the
>> newer releases. But I guess that Gerri can point the users of older
>> root releases to a patch for the netx package, which at least
>> contains that fix.
>>
>> Fabrizio
>>
>> Andreas Joachim Peters ha scritto:
>>> Hi Fabrizio, David found a memory leak using LHCb analysis in
>>> XrdClientReadCache which apparently was fixed recently by you.
>>> Do you have any good recipe to suppress the problem using the older
>>> root version 5.18.00? Will it help to set the ReadCacheSize to 0?
>>>
>>> Cheers Andreas.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> Date: Thu, 31 Jul 2008 14:42:18 +0200
>>> From: David Smith <[log in to unmask]>
>>> To: Greig A.Cowan <[log in to unmask]>
>>> Cc: Andreas Joachim Peters <[log in to unmask]>
>>> Subject: Re: DPM xrootd failures
>>>
>>> On Jul 28, 2008, at 6:11 PM, Greig A. Cowan wrote:
>>>
>>>>
>>>> On 28/07/08 16:55, David Smith wrote:
>>>>> It's probably the only way I'll be able to help you understand why
>>>>> there
>>>>> is such large memory usage here. From the DPM point of view I
>>>>> think it is
>>>>> unlikely that it is anything specific to the DPM-xroot usage, but
>>>>> unless I
>>>>> check I can't be sure.
>>>> You can find the options file on AFS:
>>>>
>>>> ~gcowan/public/optsfiles/Bs2Dspi_signal_sel_greig.opts
>>> [...]
>>>
>>> Hi Greig, Andreas,
>>>
>>> (apologies for the line wrapping my email client is probably going
>>> to do)
>>>
>>>
>>> The majority of the leak is due to
>>> XrdClientReadCache::SubmitRawData() in
>>> XrdClientReadCache.cc. The code in the executable corresponds to
>>> this snippet:
>>>
>>> if (pos >= 0) { itm = new XrdClientReadCacheItem(buffer, begin_offs,
>>> end_offs,
>>> GetTimestampTick()); fItems.Insert(itm, pos); fTotalByteCount +=
>>> itm->Size();
>>> fBytesSubmitted += itm->Size(); } return true;
>>>
>>> quickly looking through CVS I see a recent (5 weeks old) revision in
>>> the
>>> root/xrootd repository changing it to:
>>>
>>> if (pos >= 0) { itm = new XrdClientReadCacheItem(buffer, begin_offs,
>>> end_offs,
>>> GetTimestampTick()); fItems.Insert(itm, pos); fTotalByteCount +=
>>> itm->Size();
>>> fBytesSubmitted += itm->Size(); return true; } return false;
>>>
>>> (see
>>>
>>> http://root.cern.ch/viewvc/vendors/xrootd/current/src/XrdClient/XrdClientReadCac
>>>
>>> he.cc?view=log
>>> )
>>>
>>>
>>> changing the binary to be equivalent to this fixes the worst of the
>>> memory
>>> usage.
>>>
>>> Andreas, do you know more about the specifics of this, e.g. if there
>>> is a
>>> version of the analsyis framework might have the change included -
>>> or if this
>>> particular problem has been discussed with a some other recommended
>>> workaround?
>>>
>>>
>>> Yours,
>>> David
>>> --
>>> -------------------------------------------------------------------------
>>>
>>> David Smith e-mail: [log in to unmask] tel: +41 22 76
>>> 70677
>>> Address: D. Smith, CERN G20800, Bat 31 2-003, 1211 Geneva 23,
>>> Switzerland
>>> -------------------------------------------------------------------------
>>>
>>>
