Re: question about TBasket::ReadBasketBuffers line 436

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Wed, 2 Feb 2011 13:13:30 -0600


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:13:36 CET

This archive was generated by hypermail 2.2.0 : Wed Feb 02 2011 - 23:50:01 CET