Hi,
Sorry for the somewhat late action. Binaries for slc4_ia32_gcc34 are
available at
/afs/cern.ch/sw/lcg/contrib/proof/root/5.18.00e-rc/slc4_ia32_gcc34/root
This is the standard LCG build + the MonAlisa plug-ins compiled
using the MonAlisa
installation at
/afs/cern.ch/user/a/alicecaf/public/monalisa/install/
Cheers, Gerri
Sergey Panitkin wrote:
> Hi Gerri,
>
> Yes, we are eager to test the new 5.18 branch.
> And binaries for slc4_ia32_gcc34 would be great. Thanks!
>
> Is it possible to compile it with MonaLisa flag ?
> We would like to test ML based monitoring framework for PROOF too.
>
> Cheers,
> Sergey
>
> Gerardo Ganis wrote:
>>
>> 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
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>>
