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