RE:Just another SEGV ...

From: Masaharu Goto (MXJ02154@nifty.ne.jp)
Date: Tue Aug 17 1999 - 14:15:45 MEST


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                    **



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:38 MET