Re: question about TBasket::ReadBasketBuffers line 436

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 - 20:57:16 CET