On Fri, 29 May 1998, Valery Fine wrote:
> Usually this means you delete things twice somehow.
> Depends of the real memory allocation the code either crashes or
> survives.
Hi,
yes but it is not me doing this. I have a toy example which has the
same problem.
Consider this:
myclass.hh:
#ifndef __myclass__
#define __myclass__
class myclass {
public:
myclass();
~myclass();
void myprint() const;
void SetX( const float & x );
void SetY( const float & y );
private:
float fX; // x position in centimeters
float fY; // y position in centimeters
};
#endif
myclass.cc:
#include <stdio.h>
#include "myclass.hh"
myclass::myclass() : fX(-1), fY(-1) {}
myclass::~myclass() {}
void myclass::SetX( const float & x ) { fX= x; }
void myclass::SetY( const float & y ) { fY= y; }
void myclass::myprint() const {
printf("fX = %f, fY = %f\n",fX,fY);
}
rootmain.cc:
#include "TROOT.h"
#include "TRint.h"
int Error;
extern void InitGui();
VoidFuncPtr_t initfuncs[] = { InitGui, 0 };
TROOT root( "Rint", "The ROOT Interactive Interface", initfuncs );
int main( int argc, char **argv ) {
TRint *theApp = new TRint( "ROOT example", &argc, argv, NULL, 0 );
theApp->Run();
return(0);
}
rootcint step:
rootcint -f myclassCint.cc -c myclass.hh
I compile this with:
cxx -g -I${ROOTSYS}/include -o myclassroot rootmain.cc myclass.cc
myclassCint.cc -L${ROOTSYS}/lib -lNew -lBase -lCint -lRint -lClib -lCont
-lFunc -lGraf -lGraf3d -lHist -lHtml -lMatrix -lMeta -lMinuit -lNet
-lPostscript -lProof -lTree -lUnix -lZip -lGpad -lGui -lGX11 -lX3d
-L/usr/lib -lX11 -lm
And I start my custom root:
[online04] ~/scratch > myclassroot
*******************************************
* *
* W E L C O M E to R O O T *
* *
* Version 2.00/07 19 May 1998 *
* *
* You are welcome to visit our Web site *
* http://root.cern.ch *
* *
*******************************************
CINT/ROOT C/C++ Interpreter version 5.13.55, May 16 1998
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] .class myclass
===========================================================================
class myclass
size=0x8
(tagnum=452,voffset=-1,isabstract=0,parent=-1,gcomp=0,=~cd=0)
List of base class--------------------------------------------------------
List of member variable---------------------------------------------------
Defined in myclass
0x0 private: float fX //x position in centimeters
0x0 private: float fY //y position in centimeters
List of member function---------------------------------------------------
Defined in myclass
filename line:size busy function type and name
(compiled) 0:0 0 public: myclass myclass(void);
(compiled) 0:0 0 public: void myprint(void) const;
(compiled) 0:0 0 public: void SetX(float& x);
(compiled) 0:0 0 public: void SetY(float& y);
(compiled) 0:0 0 public: myclass myclass(myclass&);
(compiled) 0:0 0 public: void ~myclass(void);
root [1] myclass* bla= new myclass();
root [2] delete bla;
Fatal in <operator delete>: storage area overwritten
aborting
IOT trap (core dumped)
The class works fine in interpreted mode, probably because in this case
the destructor of myclass is ignored by root. I also ran in the debugger,
confirming where the crash originates, here is the relevant extract of the
traceback:
#8 0x3ffbf55b978 in Fatal(0x3ffbfee1fe0, 0x3ffbfee2010, 0x2,
0x3ffffdb91f0, 0x1, 0x3ffffdb91f8) DebugInformationStrippedFromFile21
#9 0x3ffbfee2d1c in operator delete(0x1, 0x3ffffdb91f8, 0x120004e8c,
0x11fffa7c8, 0x11fffa9c0, 0x140774d40) DebugInformationStrippedFromFile2
#10 0x120004e88 in ((myclass*)0x14077ae60)->~myclass() myclass.cc:6
#11 0x120005434 in G__myclass_wAmyclass_6_0(result7=0x11fffa7c8,
funcname=0x0, libp=0x11fffa9c0, hash=0) myclassCint.cc:73
#12 0x3ffbf73ad20 in G__call_cppfunc(0x0, 0x3ffffbdd640, 0xffff,
0x140774d68, 0x70, 0x0) DebugInformationStrippedFromFile40
The line myclassCint.cc:73 is part of a so-called "automatic destructor"
generated by rootcint and looks like this:
else if(G__PVOID==G__getgvp()) delete (myclass *)(G__getstructoffset());
Any ideas? Do you know how to obtain a version of root compiled without
optimisation and with debug information? Perhaps this would help in
locating the problem.
cheers, Stefan
---Stefan Kluth---------------Lynen Fellow----------------|\--|\-------
- LBNL, MS 50A 2160 - phone: +1 510 495 2376 - |/ |/ -
- 1 Cyclotron Rd. - fax: +1 510 495 2957 - |\/\|\/\|' -
---Berkeley, CA94720, USA-----e-mail: SKluth@lbl.gov------|/\/|/\/|----
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:33 MET