[cgma-dev] cgm-cubit on 32 bit machine

Iulian Grindeanu iulian at mcs.anl.gov
Fri Jul 1 11:29:03 CDT 2011



----- Original Message -----
> On 07/01/2011 11:00 AM, Iulian Grindeanu wrote:
> 
> >>
> > So the corruption in that string happens exactly when I step over
> > the
> > NCubitFile::CCubitFile ccf; statement.
> >
> > That class/object has something, because I cannot step into any of
> > its
> > methods (or constructor), the debugger skips over it; I will try
> > rebuilding with -O0 flag (it is configured with enable-debug and
> > disable-optimize, but I do not see -O0 anywhere in makefiles)
> >
> > Does anyone else, besides Rajeev and I, builds cgm on 32 bit
> > machine?
> >
> 
> If you're linking against Cubit, then your choice of compiler flags
> will not
> help. Cubit is already compiled, with whatever compiler flags the
> Cubit
> developers used.
> 
> The problem is almost certainly that the CCubitFile class increased in
> size
> between Cubit 12.0 and Cubit 12.2. The header we have is from Cubit
> 12.0.
> So the compiler allocates enough space on the stack for the 12.0-sized
> CCubitFile object but the actual constructor in libcubiti19.so
> initializes
> members of a 12.2-sized CCubitFile object, which happens to be bigger
> and
> therefore overwrites other stuff on the stack.


I think I understand now. We are using CubitFile.hpp from cgm/util folder, to compile, but we link against libcubiti19.so ? So do we need CubitFile.cpp in util? Or the files from util are not used at all?

> 
> The best solution to this, if possible, is to get a copy of the
> CCubitFile
> source from Cubit12.2 and update our copy appropriately (possibly with
> some
> preprocessor logic if we want to stay compatible with other versions
> of Cubit.)
> 
> If that is not possible the next best thing would be to guess a
> sufficiently
> large size (with enough time and some memory tricks, we could probably
> narrow that down fairly well) and add some junk (e.g. a char array) to
> our
> version of CCubitFile to make it sufficiently large. Of course this is
> unlikely work work if CCubitFile has inlined functions for which the
> implementation or the location of the relevant data in the class
> changed.
> 
> - jason




More information about the cgma-dev mailing list