Hi Volker,
when following Masa's recipe and it still crashes it is easy
to test if it is related to the ROOT custom new/delete. Just
compile your app without the ROOT libNew. On how to do that
see the $ROOTSYS/test/Makefile and add to the root-config statemenet
--nonew, like: root-config --nonew -libs
Let us know.
Cheers, Fons.
>
> Dear Volker,
>
> I suspect both problems have the same root cause. I haven't been able
> to look into the detail, it is likely that combination of compiled class
> and interpreted class has something to do. Can you avoid following cases?
>
> // Interpreted class inherits from Compiled class
> class Interpreted : public Compiled {
> };
>
> // Interpreted class has Compiled class object as a member
> class Compiled;
> class Interpreted {
> Compiled x;
> };
>
> In theory, above should work, but there is a risk associated with
> operator new/delete. Instead, please try following.
>
> class Compile;
> class Interpreted {
> Compiled *p;
> public:
> Interpreted() { p = new Compiled; }
> ~Interpreted() { delete p; }
> };
>
> Could you implement EMModule in this way?
>
> The problem can be deeper than it looks at glance. In C++, what looks
> simple can be a mess in the back.
>
> I hope this can be fixed in Root/cint, but can not say for sure.
> If problem comes from conflicting 'operator new/delete' definition
> between the standard library and Root library there is not much
> we can do.
>
> Thank you
> Masaharu Goto
>
> ------------------------------------------------------------------
> Hi,
>
> again, I had a problem with a segmentation violation:
>
> Assuming the class EMModule from my previous mails, I introduced the
> following class:
>
> [...]
>
> class EMCalo {
> private:
> EMModule *Modules;
>
> public:
> EMCalo(int modnum = 1000);
> ~EMCalo();
> void ReadCalFile(char* n);
> };
>
> [...]
>
> EMCalo::EMCalo(int modnum) {
> Modules = new EMModule[modnum];
> }
>
> EMCalo::~EMCalo() {
> delete Modules;
> }
>
> void EMCalo::ReadCalFile(char *n) {
> Int_t Rn, Mn, Nn;
> Float_t x,y,z,size;
>
> ifstream setup(n);
> while (!setup.eof()) {
> setup >> Rn;
> setup >> Mn;
> setup >> x >> y >> z >> size;
> cout << Rn << " " << Mn << " "
> << x << " " << y << " "
> << z << " " << size << endl;
>
> Nn = 60*Rn + Mn;
> Modules[Nn] = EMModule(x,y,z,size);
> }
> setup.close();
> delete setup;
> }
>
> In root, the following happens:
>
> root [2] EMCalo *test = new EMCalo(1000);
> root [3] test->ReadCalFile("current_setup.par");
> 1 1 -11.8659 59.6538 226.993 12.2465
> 1 2 -33.7912 50.572 226.993 12.2465
>
> *** Break *** segmentation violation
> Root >
> root [4] test->ReadCalFile("current_setup.par");
> 1 1 -11.8659 59.6538 226.993 12.2465
> 1 2 -33.7912 50.572 226.993 12.2465
> 1 3 -50.572 33.7912 226.993 12.2465
> 1 4 -59.6538 11.8659 226.993 12.2465
> ...
> 13 58 60.7391 226.681 12.2989 12.2465
> 13 59 36.7117 231.789 12.2989 12.2465
> 13 60 12.2821 234.356 12.2989 12.2465
> 13 60 12.2821 234.356 12.2989 12.2465
> root [5]
>
> That means, that the file could be read successfully the second
> (and third, ...) time, but not during the first call. After that,
> reloading of macros is no longer possible.
>
> I thought, one the big advantages of root is, that one can build
> some analysis code in the frame of macros first and then, later on,
> they can be compiled and loaded as a shared library. This works,
> of course, but in the macro stage I get a lot of SEGV, which turn
> the advantage in a disadvantage again.
>
> Is this real or did I miss a very essential point?
>
> Thanks in advance and best reagrds,
> Volker
>
> --
> Volker Hejny Tel: 02461/616853 **
> Institut f. Kernphysik Fax: 02461/613930 **
> ---------------------------------------------------------------- ** ** ---
> Forschungszentrum Juelich GmbH, D-52425 Juelich **
>
--
Org: CERN, European Laboratory for Particle Physics.
Mail: 1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:38 MET