[cgma-dev] cgm-cubit on 32 bit machine
Jason Kraftcheck
kraftche at cae.wisc.edu
Fri Jul 1 10:09:22 CDT 2011
On 07/01/2011 09:49 AM, Iulian Grindeanu wrote:
> Hi Jane, I am trying to use cgm, cubit version on my laptop, and there is
> a crash when running
>
> testgeom tridata1.cub.
>
> This affects other tests in meshkit, which use cubit files as geometry
> sources.
>
> The memory becomes corrupted (in the debugger) right when CCubitFile is
> instantiated ( NCubitFile::CCubitFile ccf;) , line 6360. A variable that
> holds the string values for file types is defined above. const char
> *model_type_str[6] = {"", "ACIS_SAT", "", "FACET", "", "GRANITE"};
>
> After passing over ( NCubitFile::CCubitFile ccf;) in the debugger,
> model_type_str is corrupted.
>
> Maybe tmpnam use is what causes the problem (some say that tmpnam should
> never be used on linux) I tried something else (like a hard-coded tmp
> file name) and it did not fix it. So I think we can rule out tmpnam.
>
This definitely has nothing to do with tmpnam. And the issue with tmpnam is
a) a conceptual problem with the lack of atomicity resulting from the
selection of the name and the creation of the file being separate steps, not
just linux problem and b) it is certainly still present in whatever
replacement implementation you tried.
> Anyway, if I just declare a "buffer" after the file definition, like in
> NCubitFile::CCubitFile ccf; int buff[10]= {0};buff[1] =0;
>
> the memory does not get corrupted, and testgeom tridata1.cub finishes
> fine.
>
> So I am wondering if it is something wrong in CCubitFile
> object/constructor that corrupts the memory.
>
Try setting a watch point in the debugger for one of the bytes that gets
corrupted. Then you'll know where the corruption is happening.
- jason
More information about the cgma-dev
mailing list