Print

Print


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