Hi,
just to add a bit more options to this confusion: As pointed out about a
year ago this _does_ depend on whether you link against debug or not. I
never managed to pin down the problem to the code line, but this is my
interpretation of what happens:
In your case, the root libs / dlls are built using the non-debug version
of new/delete (you used --build=debug, but as you said you link against
the non-debug lib).
Your code is built in debug mode - it's calling a different set of
new/delete ops. If you delete an object that was created using the
non-debug ("release") new op, delete will run into problems, as it
expects (and wants to free) some debug allocation surrounding the memory
allocated by the prior "new" call, which was not allocated by the
release-new.
This should only happen when a user new hits a precompiled delete and
vice versa.Can you check that? Is the delete that causes the exception a
delete on (part of) an object that you allocated calling new?
If it is: You'll have to switch root versions to use exactly the same
runtime lib as your code uses.
Cheers, Axel.
----- Original Message -----
From: "Faine, Valeri" <fine@bnl.gov>
Date: Wednesday, October 16, 2002 10:44 pm
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
> whenit
> > 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
> givean
> > 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
> statementto
> > > 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
> youcan
> > > 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
> witha
> > > > > > 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