Re: question about TBasket::ReadBasketBuffers line 436

Yes, it is also there.
Cheers,
Philippe.

On 2/2/11 1:32 PM, Constantin Loizides wrote:
> Hi Philippe,
> thanks for the fix. I assume this will go into
> the v5-28-00 patches as well?
> Constantin
>
> On 02/02/2011 08:13 PM, Philippe Canal wrote:
>> Hi Constantin,
>>
>> Yes this is indeed a problem (but the return shown below is too early).
>> The problem is fixed by revision 37947 of the trunk.
>>
>> Thanks,
>> Philippe.
>>
>> On 1/26/11 3:39 AM, Constantin Loizides wrote:
>>> Dear experts,
>>> I have a question regarding the error handling
>>> in TBasket line 436. In the original version
>>> an unzipping error is recognized, badread is set
>>> to one, but then the code continues. I am not
>>> sure if this is intended, but I could imagine it
>>> is trying to repair the bad read. However, very
>>> often (or even always?) the code the crashes
>>> later in the "AfterBuffer" section, ie in
>>> fBufferRef->ReadArray(fEntryOffset);
>>> (at least in the cases I looked at).
>>>
>>> Now in my case, if I return immediately the bad return,
>>> I can nicely detect the bad read and decide to
>>> abort the current event, or even reading the current
>>> event.
>>>
>>> My question is: What is the intended behavior and
>>> would there be a way to make this method a bit more
>>> robust so that jobs do not crash when the unzip is
>>> detected?
>>>
>>> Thanks,
>>> Constantin
>>>
>>>
>>> Index: tree/tree/src/TBasket.cxx
>>> ===================================================================
>>> --- tree/tree/src/TBasket.cxx (revision 36525)
>>> +++ tree/tree/src/TBasket.cxx (working copy)
>>> @@ -421,6 +421,7 @@
>>> if (noutot != fObjlen) {
>>> Error("ReadBasketBuffers", "fNbytes = %d, fKeylen = %d, fObjlen = %d,
>>> noutot = %d, nout=%d, nin=%d, nbuf=%d", fNbytes,fKeylen,fObjlen,
>>> noutot,nout,nin,nbuf);
>>> badread = 1;
>>> + return badread;
>>> }
>>> // Switch the 2 buffers
>>> char *temp = fBufferRef->Buffer();
>>>
>
Received on Wed Feb 02 2011 - 21:05:36 CET