Re: THistpainter / TH1 mess (was [ROOT] exception on delete in win32 debug dll.)

From: Rene Brun (Rene.Brun@cern.ch)
Date: Fri Oct 18 2002 - 08:59:50 MEST


Valery,

In case you did not see my previous mail about TPaveStats and also
the ROOT release notes:
When painting a histogram TH1*h, a TPaveStats object is created
and added to h->GetListOfFunctions(). When doing h->Write(),
the TPaveStats object is also made persistent such that if you read back
the histogram and paint it, the TPaveStats object will also be paint
with the same properties (position and attributes as in the original
session)

Rene Brun

On Wed, 16 Oct 2002, Faine, Valeri wrote:

> Hello Ed, 
> 
> I can not understand. You see: TH1 class doesn't create any TPaveStats
> object at all.
> 
> How this TPaveStats became a member of fFunctions?
> 
> And this object is not persistent. This means it MUST not be written
> out.
> 
> The parent of TPaveStats is THistPainer::fFunctions rather
> TH1::fFunctions.
> However your debugging reveals it is the member of very TH1::fFunctions.
> See:
> http://root.cern.ch/root/htmldoc/src/THistPainter.cxx.html#THistPainter:
> PaintStat 
> 
> Well !!!!!  I have found I found that list is a data-member of TWO
> classes simultaneously (THistPainer::fFunctions = TH1::fFunctions )
> See:
> http://root.cern.ch/root/htmldoc/src/THistPainter.cxx.html#THistPainter:
> SetHistogram 
> 
> My guess you did draw your histogram then you wrote it out.
> Can you swap things first write it out then Draw it or just eliminate
> drawing for a while.
> 
> This may help, because the TPaveStats object is created by THistpainter
> rather by TH1F. Since both classes share one and the same list, each
> class contributes there its own object. TPaveStats created by
> THistpainter becomes a member of the histogram also and it is
> erroneously written out with the histogram (may be "by design").
> 
> If you would not draw it then no TPaveStats should have been created at
> all and it could not have been written out. Can you check this?
> 
> At this point I am forwarding this to roottalk asking about assistance
> to investigate the case further. I am lost.
> 
>          Valeri
> 
> 
> > Vareri,
> >  Oops!  I misspoke in my very first sentance:  The exception DOES
> > occur within TCollection::RecursiveRemove.  Thats why I printed the
> > the trace.
> > 
> > the fBits of TPaveStats::fParent = 0x03000000., so TestBit should
> return
> > false.
> 
>    This means it is a ROOT bug.
>    I have looked the code up more carefully
>    http://root.cern.ch/root/htmldoc/src/TH1.cxx.html#TH1:~TH1 
>    They do mark fFunctions with that bit
> 
>    if (fFunctions) { 
>       fFunctions->SetBit(kInvalidObject);
>       fFunctions->Delete(); 
>       delete fFunctions; 
>    }
> 
> However it is not "delete fFunctions" that causes the problem rather the
> member of fFunctions list. That your investigation has revealed. 
> 
> That must be protected by 
> http://root.cern.ch/root/htmldoc/src/TList.cxx.html#TList:Delete
> method. 
> 
> One can see this method sets no kInvalidObject bit at all.
> Leaving TPaveStats class object unprotected.
> 
>  Best regards,
>                        Valeri
>   
> 
> > 
> > Ed
> > > -----Original Message-----
> > > From: Faine, Valeri [mailto:fine@bnl.gov]
> > > Sent: Wednesday, October 16, 2002 5:24 PM
> > > To: 'Ed Oltman'
> > > Cc: rootdev@pcroot.cern.ch
> > > Subject: RE: [ROOT] exception on delete in win32 debug dll.
> > >
> > >
> > >  But it is BAD !!!
> > >  Because it MUST not be called at all.
> > >  This means the protection that ROOT team imposed against of this
> case
> > > "fParent->TestBit(kInvalidObject)" did not work:
> > >
> > > > >   if ( fParent && !fParent->TestBit(kInvalidObject))
> > > > >   fParent->RecursiveRemove(this);
> > >
> > > Can you make sure that bit "kInvalidObject" is set.
> > > If this is the case then this is not ROOT rather the VC++ compiler
> bug.
> > >
> > >                 Best regards, Valeri
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ed Oltman [mailto:eoltman@imago.com]
> > > > Sent: Wednesday, October 16, 2002 6:05 PM
> > > > To: Faine, Valeri
> > > > Subject: RE: [ROOT] exception on delete in win32 debug dll.
> > > >
> > > > Valeri,
> > > > The exception does not occur within TCollection::RecursiveRemove:
> > > > I put break points on TCollection::RecursiveRemove() entry and
> > > > exit when TH1::~TH1F() was deleting the TPaveStats object.  Here's
> > > > what the stack looked like when the exception occurred:
> > > >
> > > >
> > > > NTDLL! 77f8f56f()
> > > > MSVCRT! 7800b7ef()
> > > > MSVCRT! 7800b296()
> > > > MSVCRT! 7800b146()
> > > > MSVCRT! 7800b0a6()
> > > > MSVCRT! 7800aef7()
> > > > MSVCRT! 7800b83c()
> > > > NTDLL! 77f8f45c()
> > > > NTDLL! 77f8f3fa()
> > > > NTDLL! 77fa0346()
> > > > TList::Remove(TObject * 0x064bc910) line 551 + 16 bytes
> > > > TCollection::RecursiveRemove(TObject * 0x064bc910) line 283 + 18
> bytes
> > > > TPaveStats::~TPaveStats() line 80
> > > > LIBGRAF! TPaveStats::`vector deleting destructor'(unsigned int) +
> 84
> > > bytes
> > > > TCollection::GarbageCollect(TObject * 0x064bc910) line 415 + 31
> bytes
> > > > TList::Delete(const char * 0x016a8bb0) line 386 + 14 bytes
> > > > TH1::~TH1() line 478
> > > > TH1F::~TH1F() line 5632 + 50 bytes
> > > > LIBHIST! TH1F::`vector deleting destructor'(unsigned int) + 84
> bytes
> > > > CCuts::Reset() line 85 + 36 bytes
> > > > CAnalysis::Reopen() line 344
> > > > CManage::Reopen() line 156
> > > >
> > > >
> > > > Ed
> > > >
> > > >  From: Faine, Valeri [mailto:fine@bnl.gov]
> > > > > Sent: Wednesday, October 16, 2002 3:44 PM
> > > > > To: 'Ed Oltman'
> > > > > Cc: roottalk@pcroot.cern.ch
> > > > > Subject: RE: [ROOT] exception on delete in win32 debug dll.
> > > > >
> > > > >
> > > > > I think the problem is caused by
> > > > >
> > > > >   if ( fParent && !fParent->TestBit(kInvalidObject))
> > > > >   fParent->RecursiveRemove(this);
> > > > >
> > > > > statement from
> > > > >
> > > > >
> > >
> http://root.cern.ch/root/htmldoc/src/TPaveStats.cxx.html#TPaveStats:~TPa
> > > > > veStats
> > > > >
> > > > >
> > > > > when TPaveStats dtor is called from fParent dtor.
> > > > >
> > > > > At this point one can not rely on the virtual methods of fParent
> (at
> > > > > this point it is TObject ONLY). Any virtual methods may not be
> > > called
> > > > > properly because the table of the virtual function of the real
> > > object
> > > > > might have been destroyed.
> > > > > (see: http://root.cern.ch/root/htmldoc/TObject.html to see
> > > > >  virtual void RecursiveRemove(TObject* obj ) method there
> > > > >
> > > > > The result may vary depends of the compilation options
> combination.
> > > > >
> > > > > Can you check you get the crash calling that RecursiveRemove?
> > > > >
> > > > >          My best regards, Valeri
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ed Oltman [mailto:eoltman@imago.com]
> > > > > > Sent: Wednesday, October 16, 2002 3:25 PM
> > > > > > To: Faine, Valeri
> > > > > > Subject: RE: [ROOT] exception on delete in win32 debug dll.
> > > > > >
> > > > > > Hi Valeri,
> > > > > >
> > > > > > [NOTE: My last message bounced back from cern because "The
> domain
> > > > > > choiceone.net or
> > > > > > external relay through this domain is banned by the CERN." -
> we
> > > just
> > > > > > switched
> > > > > > to choiceone.net today.  This is why I cannot seem to post to
> > > > > roottalk...]
> > > > > >
> > > > > > 1. Stack question:  The pushbutton calls CAnalysis::Reopen(),
> a
> > > class
> > > > > > method
> > > > > > in
> > > > > > my dll that clears out some objects (including the call to
> delete
> > > > > > m_pDeltaTof)
> > > > > > prior to reading in a new file.
> > > > > >
> > > > > > 2. break in dtor.  I set a breakpoint in TH1::~TH1() and saw
> every
> > > TH1
> > > > > > object
> > > > > > that got deleted.  m_pDeltaTof did not appear untill I hit the
> > > line
> > > > > >   delete m_pDeltaTof
> > > > > > in response to the toolbar button press.  Here is the trace at
> > > that
> > > > > point:
> > > > > >
> > > > > > TH1::~TH1() line 472
> > > > > > TH1F::~TH1F() line 5632 + 50 bytes
> > > > > > LIBHIST! TH1F::`vector deleting destructor'(unsigned int) + 84
> > > bytes
> > > > > > CCuts::Reset() line 85 + 36 bytes
> > > > > > CAnalysis::Reopen() line 344
> > > > > > CManage::Reopen() line 156
> > > > > > G__CManage_Reopen_4_0(G__value * 0x01d63c9c, const char *
> > > 0x00000000,
> > > > > > G__param * 0x01d60f90, int 0) line 4758
> > > > > >
> > > > > > So, it is a TH1F that I'm deleting.  The crash occurs in the
> dtor
> > > when
> > > > > it
> > > > > > tries to
> > > > > > delete the TList *fFunctions.  The first is a "TF1" - the
> function
> > > > > > associated with
> > > > > > a gaus fit - that gets deleted just fine.  The other item in
> the
> > > > > > fFunctions
> > > > > > list is a
> > > > > > "TPaveStats" object.  It crashes when it attempts to delete
> this
> > > > > second
> > > > > > object.
> > > > > >
> > > > > > The reason I suspected debug dll is because the program does
> not
> > > give
> > > > > an
> > > > > > exception
> > > > > > when it built in release mode.
> > > > > >
> > > > > > Ed
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Faine, Valeri [mailto:fine@bnl.gov]
> > > > > > > Sent: Wednesday, October 16, 2002 1:21 PM
> > > > > > > To: 'Ed Oltman'
> > > > > > > Cc: roottalk@pcroot.cern.ch
> > > > > > > Subject: RE: [ROOT] exception on delete in win32 debug dll.
> > > > > > >
> > > > > > >
> > > > > > > Hi Ed,
> > > > > > >
> > > > > > > The bottom line:
> > > > > > >
> > > > > > > ---------------
> > > > > > > I don't think the problem you faced is related to "win32
> debug
> > > dll".
> > > > > > > I'd like to call your attention TH1 objects are special.
> > > > > > >  ROOT keeps it in its internal lists and may delete when it
> > > finds it
> > > > > is
> > > > > > > "appropriated".
> > > > > > > Probably you should set break point within that class dtor
> too
> > > see
> > > > > when
> > > > > > > and where this dtor was called from.
> > > > > > > ---------------
> > > > > > >
> > > > > > > Your call stacks indicates you used some sort of "ToolBar"
> class
> > > > > > > and pushed some "toolbar" button. The last sends the "Cint
> > > statement
> > > > > to
> > > > > > > be performed. That ends up somewhere within CINT with the
> > > exception.
> > > > > > > Can you tell us what this "PushButton" really does, which
> C++
> > > > > statements
> > > > > > > it emits.  It looks like this Pushbutton tried to call some
> > > method
> > > > > of
> > > > > > > your class
> > > > > > > G__CManage_Reopen_4_0.
> > > > > > >
> > > > > > > I wondering if this is very place where you call your
> > > > > > >
> > > > > > >             delete m_pDeltaTof;
> > > > > > > from.
> > > > > > >
> > > > > > > Can you set a break point just before "delete" investigating
> the
> > > > > object
> > > > > > > the m_pDeltaTof points to. Very likely this object has been
> > > killed
> > > > > > > already
> > > > > > > or R__b >> m_pDeltaTof made object of not TH1F type.
> > > > > > >
> > > > > > > I want to call you attention then when object is deleted it
> is
> > > that
> > > > > > > object class destructor job clean the memory the object
> > > occupied. If
> > > > > > > dtor doesn't clean the memory (why bother?) all data that
> > > belonged
> > > > > to
> > > > > > > the object are still there and you can see it with debugger
> but
> > > you
> > > > > can
> > > > > > > not access any method of the class anymore.
> > > > > > >
> > > > > > > I mean you mentioned
> > > > > > >
> > > > > > > > > > At the time I delete m_pDeltaTof, I can examine it
> from
> > > the
> > > > > > > debugger -
> > > > > > > > > its intact -its got a title, name, bins, bin contents,
> > > etc..]
> > > > > > >
> > > > > > > This DOESN'T mean the object was not deleted. This simply
> means
> > > the
> > > > > > > object WAS there and may or may not there now. This means
> the
> > > memory
> > > > > the
> > > > > > > object occupied has not been reused yet by another object.
> > > > > > >
> > > > > > >
> > > > > > > This should help
> > > > > > >
> > > > > > >                               Valeri
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ed Oltman [mailto:eoltman@imago.com]
> > > > > > > > Sent: Wednesday, October 16, 2002 1:05 PM
> > > > > > > > To: Faine, Valeri
> > > > > > > > Cc: roottalk@pcroot.cern.ch
> > > > > > > > Subject: RE: [ROOT] exception on delete in win32 debug
> dll.
> > > > > > > >
> > > > > > > > Valeri,
> > > > > > > >   Yes, I can debug my program, but not the way you
> describe.
> > > I
> > > > > use
> > > > > > > > Projects-->Settings-->Debug to point to the version of
> root I
> > > > > built
> > > > > > > > using cygwin w/export ROOTBUILD='debug'.  When I start the
> > > > > debugger,
> > > > > > > > I get a root window and I load my dll and start using it.
> > > > > > > >
> > > > > > > > Here's the line that causes the exception:
> > > > > > > >
> > > > > > > >      delete m_pDeltaTof;
> > > > > > > >
> > > > > > > > (called from with an object that earlier did
> > > > > > > >
> > > > > > > >      R__b >> m_pDeltaTof;
> > > > > > > >
> > > > > > > > where m_pDeltaTof is an object of type  TH1F*)
> > > > > > > >
> > > > > > > >
> > > > > > > > I'm wondering if there are any other switches that need to
> be
> > > > > > > > set when I build a debug version of root with cygwin.
> > > > > > > >
> > > > > > > > I am not using libNew.lib  - here is the list of libraries
> I
> > > link
> > > > > > > with:
> > > > > > > >
> > > > > > > > root libraries:
> > > > > > > > libCore.lib libCint.lib libHist.lib libMinuit.lib
> libGraf.lib
> > > > > > > > libGraf3d.lib
> > > > > > > > libGpad.lib libTree.lib libRint.lib libPostscript.lib
> > > > > libMatrix.lib
> > > > > > > > libPhysics.lib
> > > > > > > >
> > > > > > > > my own library (not code gets called from this)
> > > > > > > > rfftw2dll.lib
> > > > > > > >
> > > > > > > > windoze libraries:
> > > > > > > > kernel32.lib user32.lib gdi32.lib winspool.lib
> comdlg32.lib
> > > > > > > advapi32.lib
> > > > > > > > shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
> > > > > odbccp32.lib
> > > > > > > >
> > > > > > > > Thanks..
> > > > > > > >
> > > > > > > > Ed
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Here are my call stacks:
> > > > > > > >
> > > > > > > > --------Thread that prints out exception warning  (its
> name is
> > > > > > > > $L19241)---------------
> > > > > > > >
> > > > > > > > G__ExceptionWrapper(int (G__value *, const char *,
> G__param *,
> > > > > int)*
> > > > > > > > 0x06158560 G__CManage_Reopen_4_0(G__value *, const char *,
> > > > > G__param *,
> > > > > > > > int),
> > > > > > > > G__value * 0x01d63c9c, char * 0x00000000, G__param *
> > > 0x01d60f90,
> > > > > int
> > > > > > > > 0x00000000) line 357
> > > > > > > > G__call_cppfunc() line 440 + 21 bytes
> > > > > > > > G__interpret_func() line 5997 + 24 bytes
> > > > > > > > G__getfunction() line 1627 + 68 bytes
> > > > > > > > G__getitem() line 1925 + 22 bytes
> > > > > > > > G__getexpr() line 1386 + 42 bytes
> > > > > > > > G__exec_function() line 505 + 13 bytes
> > > > > > > > G__exec_statement() line 4381 + 42 bytes
> > > > > > > > G__exec_tempfile() line 379 + 12 bytes
> > > > > > > > G__process_cmd() line 3551 + 19 bytes
> > > > > > > > TCint::ProcessLine(const char * 0x01925044,
> > > > > TInterpreter::EErrorCode *
> > > > > > > > 0x00000000) line 248 + 29 bytes
> > > > > > > > TApplication::ProcessLine(const char * 0x01925044,
> unsigned
> > > char
> > > > > 0x00,
> > > > > > > int
> > > > > > > > *
> > > > > > > > 0x00000000) line 657
> > > > > > > > TControlBarButton::Action() line 63
> > > > > > > > TWin32ControlBarImp::ExecThreadCB(TWin32SendClass *
> > > 0x018cf888)
> > > > > line
> > > > > > > 136
> > > > > > > > TWin32HookViaThread::ExecuteEvent(void * 0x01d6ff5c,
> unsigned
> > > char
> > > > > > > 0x01,
> > > > > > > > unsigned int 0x0000040c) line 121
> > > > > > > > ROOT_CmdLoop(void * 0x000001ac) line 68 + 24 bytes
> > > > > > > > MSVCRT! 780060ce()
> > > > > > > >
> > > > > > > > --------Another thread  (its name is
> > > ROOT_MsgLoop)---------------
> > > > > > > >
> > > > > > > > USER32! 77e11b80()
> > > > > > > > ROOT_MsgLoop(void * 0x000001ac) line 122 + 16 bytes
> > > > > > > > MSVCRT! 780060ce()
> > > > > > > > KERNEL32! 77e96523()
> > > > > > > >
> > > > > > > > --------Another thread  (its name is
> gl_getc)---------------
> > > > > > > > NTDLL! 77f8224d()
> > > > > > > > KERNEL32! 77ec618e()
> > > > > > > > KERNEL32! 77ec6288()
> > > > > > > > gl_getc() line 607 + 5 bytes
> > > > > > > > Getlinem(int 0x00000001, const char * 0x00000000) line 794
> + 5
> > > > > bytes
> > > > > > > > TRint::HandleTermInput() line 348 + 9 bytes
> > > > > > > > TWinNTSystem::DispatchOneEvent(unsigned char 0x00) line
> 679 +
> > > 23
> > > > > bytes
> > > > > > > > TSystem::InnerLoop() line 292
> > > > > > > > TWinNTSystem::InnerLoop() line 765
> > > > > > > > TSystem::Run() line 260
> > > > > > > > TApplication::Run(unsigned char 0x00) line 821
> > > > > > > > TRint::Run(unsigned char 0x00) line 246
> > > > > > > > main(int 0x00000001, char * * 0x01304d40) line 31
> > > > > > > > ROOT! mainCRTStartup + 227 bytes
> > > > > > > > KERNEL32! 77e8d326()
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Faine, Valeri [mailto:fine@bnl.gov]
> > > > > > > > > Sent: Tuesday, October 15, 2002 10:00 PM
> > > > > > > > > To: 'Ed Oltman'
> > > > > > > > > Cc: roottalk@pcroot.cern.ch
> > > > > > > > > Subject: RE: [ROOT] exception on delete in win32 debug
> dll.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > He Ed,
> > > > > > > > > Can you debug your problem?
> > > > > > > > >
> > > > > > > > >  To do that:
> > > > > > > > >
> > > > > > > > >    1. START root session
> > > > > > > > >    2. From MS Studio say:
> > > > > > > > >       "Build" -> "Start debug" -> "Attach to process"
> > > > > > > > >    3. Go ahead with your DLL. It should catch the
> exceptions
> > > and
> > > > > you
> > > > > > > > > will see        the "call stack" (probably)
> > > > > > > > >
> > > > > > > > > Be aware you should see as many as 3 (or 4) call stacks.
> You
> > > may
> > > > > > > want to
> > > > > > > > > investigate all of them. To do that you may select the
> > > target
> > > > > thread
> > > > > > > via
> > > > > > > > >
> > > > > > > > > "Debug" ->Threads" menu.
> > > > > > > > > Make sure you did not link against of
> > > %ROOTSYS%/lib/libNew.lib
> > > > > > > library.
> > > > > > > > >
> > > > > > > > > Hope this helps.
> > > > > > > > >                           Valeri
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: owner-roottalk@pcroot.cern.ch
> > > > > > > > > [mailto:owner-roottalk@pcroot.cern.ch]
> > > > > > > > > > On Behalf Of Ed Oltman
> > > > > > > > > > Sent: Tuesday, October 15, 2002 6:14 PM
> > > > > > > > > > To: Roottalk@Pcroot. Cern. Ch
> > > > > > > > > > Subject: [ROOT] exception on delete in win32 debug
> dll.
> > > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >  I am using root v 3.03/9 on win2k.   I'm using root
> with
> > > a
> > > > > set of
> > > > > > > > > > compiled
> > > > > > > > > > classes in a dll - I'm using rootcint and a makefile
> that
> > > is
> > > > > on
> > > > > > > > > > makefile.win32.
> > > > > > > > > > Everything on the root end seems to work fine (yay!)
> > > However,
> > > > > I
> > > > > > > do
> > > > > > > > > have
> > > > > > > > > > bugs
> > > > > > > > > > in my code and need to use the debugger.  I use the
> VC++
> > > > > > > environment
> > > > > > > > > to
> > > > > > > > > > build.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Everything works fine until I try to delete an object
> that
> > > was
> > > > > > > created
> > > > > > > > > by
> > > > > > > > > > root:
> > > > > > > > > > I get an exception -- its some sort of memory
> management
> > > > > issue.
> > > > > > > (Note
> > > > > > > > > when
> > > > > > > > > > I
> > > > > > > > > > build my debug version of my dll, I use the non-debug
> > > > > > > multithreaded
> > > > > > > > > > version
> > > > > > > > > > of
> > > > > > > > > > the runtime library (LIBCMT.LIB) just to make sure the
> > > there
> > > > > is no
> > > > > > > > > heap
> > > > > > > > > > conflict.
> > > > > > > > > > [The object I tried to delete is a TH1F* that was read
> in
> > > with
> > > > > a
> > > > > > > > > > customized
> > > > > > > > > > streamer
> > > > > > > > > > using:
> > > > > > > > > >
> > > > > > > > > >       R__b >> m_pDeltaTof;
> > > > > > > > > >
> > > > > > > > > > At the time I delete m_pDeltaTof, I can examine it
> from
> > > the
> > > > > > > debugger -
> > > > > > > > > its
> > > > > > > > > > intact -
> > > > > > > > > > its got a title, name, bins, bin contents, etc..]
> > > > > > > > > >
> > > > > > > > > > So, I decided to build a debug version of root from
> the
> > > tar
> > > > > file
> > > > > > > using
> > > > > > > > > > cygwin tools.
> > > > > > > > > > Here's what I do to build it (in cygwin bash)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > export ROOTBUILD='debug'
> > > > > > > > > > ./configure win32
> > > > > > > > > > make
> > > > > > > > > >
> > > > > > > > > > Then, I tried to use the libraries and root.exe that I
> > > built
> > > > > but
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > > help - I still
> > > > > > > > > > get the same exception when I delete an object that
> root
> > > > > created.
> > > > > > > Any
> > > > > > > > > > help
> > > > > > > > > > would
> > > > > > > > > > be greatly appreciated..
> > > > > > > > > >
> > > > > > > > > > Ed
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> 



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:15 MET