CVI 2013 crash with debug build

[tstanley]

Hi,

I'm trying to migrate a largish project from CVI 2012SP1 to CVI 2013, and am experiencing a crash of the clang compiler when I attempt a debug build on some files.  Clang will also crash ("Labwindows/CVI Compiler Clang has stopped working...") if I simply attempt to compile the file (ctrl-k) while in the editor.  Here's what I have found:

• A release build does not crash
• Turning C99 on/off has no effect
• Changing the warning level has no effect (other than the types of warnings I get, obviously)
• Changing the "Debugging level" to "No run-time checking" eliminates the crash.
• "Enable .Obj Option" eliminates the crash.
• Turning pre-compiled headers on/off has to effect.

Here's the rather lengthy message I get from the compiler when this happens (including all the warnings that still show up when the warning level is set to "None"):

Any thoughts?  Unfortunately it's a rather large project that I can't post, and there doesn't seem to be any indication of the line(s) in the file it is having trouble with so I can't seem to narrow it down, though it does seem to hint that it is having problems with structures of some sort.  The PC is running Windows 7 Pro 32-bit if that matters.

Thanks.

[OVR_CZ]

Hi,

I solve this type of errors by isolating the "crash-line". By trying comment out /**/ all functions and code so long, to force compiler to not crash.

After finding the "crash line", i try change the line to "something" which do not cause compiler crash 🙂

It is hard to catch what is exactly wrong, sometimes it seems that there is combination of factors. So i try to write some notes about my solution hunting.

   1)Create large data variable dynamicaly (by malloc or so) instead of static definition (like TBigStructure array[10000000])

      There is another compiler error which suggest this change, but i found this helped me in this case too.

   2)use temporary (void *) variable instead of direct pointer re-type

      also check that struct has correct padding (#pragma pack(...)) in case of wild re-type

//Line similar like this may in some situation cause compiler to crash
Function((int*)&data[x].variable);

//this work without crash
void *pTemp=&data[x].variable;
Function((int*)ptemp);

Also I have some issues with partial initialized structures combined with pointer to structure member.

It is something like combination of the above points, but am not sure what exactly helped because i change this code a lot.

I hope this help.

P.S. sorry for my bad english

[D_Biel]

Hi tstanley,

Could you tell me what the memory characteristics of the system are at the time of the crash. Specifically, how much memory is clang.exe using, how much is the CVI environment using, and how much free memory is available.

I'm also guessing that this crash only occurs with this project, and does not occur with other projects. Is there any way you could remove some portion of the project to reduce its size and determine if it is still compiling? What I am trying to determine is if the error is occurring because of an issue compiling some part of the code, or because of the size of the project.

[tstanley]

Hi D_Biel,

At the time of the crash (when compiling the file), I have CVI using 113,376K and Clang using 121,524K of memory, according to Windows Task Manager.  Task Manager also shows 876M Cached, 843M Available, and 2M Free out of 2046M total memory.  

I did experiment around with excluding large parts of the file to see if I could get it to build.  After playing around a while, I think OVR_CZ is on the right track and it has to do with structures.  I was able to distill it down to a few global/functions that have to deal with a particular structure in the file.  Based upon this, I've attached a small project which shows the problem.  The project won't actually run as there is no main() function, but to duplicate the crash (as seen on my system) all you should have to do is open test2.c in the IDE and then select "Compile File" (ctrl-k).  Hopefully this helps.

Thanks.

[D_Biel · Accepted solution]

Hi tstanley,

We were able to find the root cause of this compiler crash from your code. We will be fixing it in the next update and you can track it with bug ID 422577.

The issue occurs when in one function you have a call to a function that returns a struct into a global variable, and then reference that global in another function. For example:

struct Foo foo; // global variable foo

void FuncA()
{
foo = GetStructFoo();
}

void FuncB()
{
do something with foo // crash
}

The reason this happens is because we are incorrectly associating temporary pointer information with foo in FuncA. Then in FuncB, clang will crash when it tries to access this pointer information.

There are two workarounds, but both require code changes.

1. Modify the function that returns the struct, GetStructFoo in my example, to return it through a pointer parameter:

void GetStructFoo(Foo *foo);

2. Use a temporary local variable to handle the returned struct and then assign it's value to the global struct:

struct Foo tempFoo;

tempFoo = GetStructFoo();

foo = tempFoo;

We will be including the fix for this bug in our next update.

[tstanley]

Hi D_Biel,

Getting rid of function calls that return struct into a global does seem to get rid of the crashes.  I'm not sure if we are going to migrate to CVI 2013 quite yet, but at least I know I could do it.  Thanks for your help.

[tstanley]

I'm not sure if it's the same problem or not, but I am also having problems with code like this where I set a local pointer in a function to a pointer to a global structure.  Just thought I would make a note here to be sure.  Thanks.

struct foo
{
  int a;
  int b;
}

struct foo bar;

void initialize(void)
{
  int *ptr1, *ptr2;

  ptr1 = (int *)bar;
  ptr2 = (int *)bar + sizeof(struct foo);

  while(ptr1 < ptr2)
  {
     *ptr1 = -1;
     ++ptr1;
  }
}

[LuisG]

HI tstanley,

What problems exactly are you having with this code? Should bar really be an instance of foo, or a pointer to an instance of foo?

Luis

[tstanley]

Sorry, foo should be a pointer to bar, and there should be a sizeof(struct foo) / sizeof(int) in there too.  That's what I get from trying to type some code from memory into a web browser on a different PC. 

Interestingly, I can't get that sample program to crash, though very similar code causes a crash when compiling in a much larger project (and excluding the lines causes the crash to go away) .  I may have to do some more investigation to see if I can get a sample program to do the same thing.