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

Jiangtao Hu jiangtao_ma at yahoo.com
Fri Jul 1 10:47:36 CDT 2011


Hi, Iulian

I am sorry I can't be more helpful. It could be as you described, but I don't see any memory allocation happen in the the CCubitFile constructor. And myslef is not very familiar with memory management related to file read/write.

While Tim is there, I think he is the best one you can get help from.

Good luck!

Jane

--- On Fri, 7/1/11, Iulian Grindeanu <iulian at mcs.anl.gov> wrote:

From: Iulian Grindeanu <iulian at mcs.anl.gov>
Subject: cgm-cubit on 32 bit machine
To: "Jiangtao Hu" <jiangtao_ma at yahoo.com>
Cc: cgma-dev at mcs.anl.gov
Date: Friday, July 1, 2011, 10:49 AM

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.

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. 

This does not show up on a 64 bit machine;

Any suggestions?

Iulian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20110701/9db43e82/attachment.htm>


More information about the cgma-dev mailing list