RE: [ROOT] exception on delete in win32 debug dll.

From: Faine, Valeri (fine@bnl.gov)
Date: Wed Oct 16 2002 - 22:44:02 MEST


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:14 MET