Hi Clark,
I have checked that your proposed fix is OK and indeed fixes the recurvity
problem with your small example.
Thanks for this contribution.
Rene Brun
Clark McGrew wrote:
>
> Hello,
>
> I've isolated a corner case where the correction to
> TStreamerInfo::ForceWriteInfo() made in TStreamerInfo.cxx: version 1.161
> causes an infinite recursion.
>
> class aProblemChild: public TNamed {
> aProblemChild *canBeNull;
> };
>
> When ForceWriteInfo() is called for this with force=kTRUE, the
>
> if (cindex->fArray[fNumber] && !force) return;
>
> logic will cause it to try and write an infinite number of aProblemChild
> info records.
>
> I'm not sure of the appropriate correction. I think the problem is that
> all "unforced" elements should be forced onto the output, but only
> once. A solution that might work is to apply this patch
>
> >>>>>>>>>>>>>>>>>>>
> diff -u -r1.163 TStreamerInfo.cxx
> --- TStreamerInfo.cxx 2003/03/11 01:18:47 1.163
> +++ TStreamerInfo.cxx 2003/03/31 18:07:43
> @@ -809,8 +809,9 @@
> // flag this class
> if (!file) return;
> TArrayC *cindex = file->GetClassIndex();
> - if (cindex->fArray[fNumber] && !force) return;
> - cindex->fArray[fNumber] = 1;
> + if ((cindex->fArray[fNumber] && !force)
> + || cindex->fArray[fNumber]>1) return;
> + cindex->fArray[fNumber] = 2;
> cindex->fArray[0] = 1;
> <<<<<<<<<<<<<<<<<<<<<<
>
> This appears to work, but there may be effects that I'm not aware of.
>
> Thanks,
> Clark
>
> On Sun, 2003-03-30 at 22:05, Clark McGrew wrote:
> > Hello Again,
> >
> > I did some digging to isolate the problem I reported below. The crash
> > I'm seeing is caused in the custom streamer introduced in
> > TBranchElement.cxx between version 1.104 and 1.105. I will try to
> > generate some example code to tickle the bug, but the symptom is that
> > TBranchElement::Streamer() calls TStreamerInfo::ForceWriteInfo() by way
> > of fInfo. TStreamerInfo::ForceWriteInfo() recurses infinitely until the
> > stack is full. I haven't figured out why ForceWriteInfo is stuck in
> > infinite recursion.
> >
> > I see the symptom with 3.05.03, and it first appears with in cvs
> > versions for 6 March 2003. I'm working on debian linux with g++-3.2.
> > I'm sorry this is a little vague at the moment, and will try to get some
> > example code soon.
> >
> > Thanks,
> > Clark
> >
> > On Sun, 2003-03-30 at 14:31, Clark McGrew wrote:
> > > Hi Rene,
> > >
> > > Thanks so much for replying on a Sunday. At first I thought it was a
> > > compile or LD_LIBRARY_PATH problem, and have check three ways backward
> > > and forward. I keep several versions of root on my machine, so it is
> > > possible that I've goofed. I'll delete all the objects one more time
> > > and triple check all the paths.
> > >
> > > Personally, I suspect that it's a deep, nasty bug in my code that is
> > > just now being tickled. I just wanted to make sure the interface hadn't
> > > changed before I starting a major I/O debugging session.
> > >
> > > Thanks,
> > > Clark
> > >
> > > On Sun, 2003-03-30 at 11:17, Rene Brun wrote:
> > > > Hi Clark,
> > > >
> > > > This type of trouble may appear when you have a mismatch
> > > > in your LD_LIBRARY_PATH or you did not recompile some of your classes.
> > > > Root version 3.05/03 is back compatible with previous versions.
> > > >
> > > > Rene Brun
> > > >
> > > > On
> > > > 30 Mar 2003,
> > > > Clark McGrew wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm running into a problem reading and writing files using TFile that
> > > > > appeared when I upgraded from 3.05.02 and 3.05.03. This isn't a "bug
> > > > > report", but I am checking to see if anybody else has seen a problem, or
> > > > > if there is a known interface change that I've missed before I start a
> > > > > major "what changed" debug.
> > > > >
> > > > > The problem occurs when I am about to close a TFile with the approximate
> > > > > idiom:
> > > > >
> > > > > aTFile.Write();
> > > > > aTFile.Close();
> > > > >
> > > > > This works in 3.05.02, and core dumps in 3.05.03. Also, I can't read
> > > > > files written with 3.05.02 using 3.05.03 (files look fine with '02).
> > > > > If there haven't been any expected changes in the tfile semantics, I'll
> > > > > chase down a short code snippet to isolate the problem.
> > > > >
> > > > > Thanks in advance.
> > > > >
> > > > > Clark
> > > > >
> --
> Clark McGrew <clark.mcgrew@sunysb.edu>
> University at Stony Brook, Dept. of Physics and Astronomy
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:10 MET