[ROOT] Re: test program on linux

From: Rene Brun (Rene.Brun@cern.ch)
Date: Thu Aug 19 2004 - 11:16:45 MEST


Hi Brandon,

As I already reported to you, I cannot reproduce your problem.

Note that if you modify TKey as you suggest, YOU MUST GET AN ERROR.
The line
Int_t testValue = (Int_t)fSeekKey;
is not correct. Testing testValue<0 will automatically happen when
your file reaches 2 GBytes.

Rene Brun

> Brandon Kohn wrote:
> 
> Hello Rene,
> 
> 
> Here is a test program/makefile bit for linux that will reproduce the problem
> I'm seeing. Have you had a chance to run any more tests?
> 
> Thanks much!
> 
> Brandon
> 
> ---Below is a message that bounced back when I tried to post on roottalk.
> 
> Hello rooters,
> 
> I've been experiencing some sporadic trouble with key writing on files over
> 2 gigabytes, and I would like to get some confirmation from an external
> party that the bug I'm seeing is indeed happening on other machines.
> 
> In order to see the bug, you must make a small change to TKey.cxx (a simple
> conditional test with a message output to a file and stdout.)
> 
> here is the diff for my TKey.cxx from the current cvs HEAD:
> 
> RCS file: /user/cvs/root/base/src/TKey.cxx,v
> 
> retrieving revision 1.44
> 
> diff -r1.44 TKey.cxx
> 
> 937a938,950
> 
> > ///This will allow you to check when the error occurs with a debug break
> or file output.
> 
> > ///HACK: try to correct incorrectly identified seekKeys.
> 
> > Int_t testValue = (Int_t)fSeekKey;
> 
> > if(testValue < 0 && fVersion <= 1000)
> 
> > {
> 
> > std::cout << "It happened!" << std::endl;
> 
> > std::ofstream ofs("c:/errorfileroot.txt",std::ios::app);
> 
> > ofs << "File pointer using int when long64." << std::endl;
> 
> > ofs << "File end value: " << gFile->GetEND() << std::endl;
> 
> > ofs << "File name: " << gFile->GetName() << std::endl;
> 
> > ofs << "On object: " << this->GetName() << std::endl;
> 
> > ofs.close();
> 
> > }
> 
> Or simply replace the TKey::Streamer method with the following...
> 
> //_______________________________________________________________________
> void TKey::Streamer(TBuffer &b)
> {
> //*-*-*-*-*-*-*-*-*Stream a class object*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> //*-*              =========================================
>    Version_t version;
>    if (b.IsReading()) {
>       b >> fNbytes;
>       b >> version; fVersion = (Int_t)version;
>       b >> fObjlen;
>       fDatime.Streamer(b);
>       b >> fKeylen;
>       b >> fCycle;
>       if (fVersion > 1000) {
>          b >> fSeekKey;
>          b >> fSeekPdir;
>       } else {
>          Int_t seekkey, seekdir;
>          b >> seekkey; fSeekKey = (Long64_t)seekkey;
>          b >> seekdir; fSeekPdir= (Long64_t)seekdir;
>       }
>       fClassName.Streamer(b);
>       fName.Streamer(b);
>       fTitle.Streamer(b);
>    } else {
>       b << fNbytes;
>  ///This will allow you to check when the error occurs with a debug break or
> file output.
>  ///HACK: try to correct incorrectly identified seekKeys.
>  Int_t testValue = (Int_t)fSeekKey;
>  if(testValue < 0 && fVersion <= 1000)
>  {
>   std::ofstream ofs("c:/errorfileroot.txt",std::ios::app);
>   ofs << "File pointer using int when long64." << std::endl;
>   ofs << "File end value: " << gFile->GetEND() << std::endl;
>   ofs << "File name: " << gFile->GetName() << std::endl;
>   ofs << "On object: " << this->GetName() << std::endl;
>   ofs.close();
>   fVersion += 1000;
>  }
>       version = (Version_t)fVersion;
>       b << version;
>       b << fObjlen;
>       if (fDatime.Get() == 0) fDatime.Set();
>       fDatime.Streamer(b);
>       b << fKeylen;
>       b << fCycle;
>       if (fVersion > 1000) {
>          b << fSeekKey;
>          b << fSeekPdir;
>       } else {
>          b << (Int_t)fSeekKey;
>          b << (Int_t)fSeekPdir;
>       }
>       fClassName.Streamer(b);
>       fName.Streamer(b);
>       fTitle.Streamer(b);
>    }
> }
> 
> After making this change, recompile root.. and then compile and run the test
> that I've included. The test simply creates a TFile and begins filling it
> with both large and small instances of a CBinaryLargeObject class (which is
> included). It it essential that you run the case exactly as I have included
> it as I've found that the problem only occurs with a mixture of size types
> for the Binary Large Objects.
> 
> I've included a tar.gz'd version of the example that hopefully illustrates
> the bug...
> 
> Please let me know if you are able to replicate this.
> 
> --Kindest Regards
> 
> ____________________________________________________________
> Brandon Kohn                        Tel.: +377 97 97 41 51
> Software Developer
> The Maia Institute                   Fax.: +377 97 97 41 59
> Le Patio Palace
> ____________________________________________
> 
> Important Notice
> 
> This email and any attachments to it are confidential and intended solely
> for the individual(s) to whom they are addressed.  Any modification or
> dissemination of the contents of this e-mail is strictly prohibited unless
> expressly authorised by the sender.  If you receive this e-mail by mistake,
> please advise the sender immediately by using the reply facility in your
> e-mail software.  Please also delete the message from your computer, and
> destroy any paper copies. Thank you for your co-operation.
> 
>                          Name: testbigfile.tar.gz
>    testbigfile.tar.gz    Type: Unix Tape Archive (application/x-tar)
>                      Encoding: base64



This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:09 MET