LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

clang crash in CVI2012

Hello,

 

today I attempted to recompile an old project with the new CVI2012. In debug mode, everything went fine, i.e. no warnings, no errors, but when I switched to release mode (32bit), I encountered problems...

 

The first surprise was the appearance of the JIT-debugger:

 

clang.png

 

 

While still reading the message, CVI got impatient with me:

 

cvi.png

 

It appears that CVI is waiting for the debugger, and since the debugger is waiting for my decision, I chose 'Yes'.

 

I started the debugger, which turned out not to be especially useful:

 

debugger.png

 

As mentioned before, I did have compiled the source with CVI2012 in debug mode, so I found this note a bit confusing. Of course, if 'process' refers to clang.exe, this makes more sense

 

After pressing 'OK', I learnt:

 

debugger_II.png

 

 

As I understand it, this is the way to tell me that the debugger is going to be of no help here...

 

So I cancelled it ('Break') - anyway, there is no alternative... - and was able to continue compilation. During compilation, the 'time out' due to repeated debugger popups appeared - the project consists of about 40 source files, and obviously about 12 of them had errors.

 

So after pressing 'Yes, please continue compilation' and 'Cancel, no, don't debug you will not find anything anyway' about 12 times CVI displayed the build output window - uff, this was a major effort on my side not seen before Smiley Surprised

 

It appears that there about 12 source files with warnings/errors.

 

I don't think that compilation errors should cause CVI/clang to crash...

 

The errors are of the kind  

 

1, 1   Stack dump:
1, 1   0. Program arguments: c:\Program Files (x86)\National Instruments\CVI2012\bin\clang\clang-cc.exe -triple i386-pc-win32 -emit-o -ffreestanding -fno-caret-diagnostics --std=c99 -D _CVI_C99_EXTENSIONS_ -Wall -Wno-unknown-pragmas -O2 @C:\DOCUME~1\Wolfgang\LOCALS~1\Temp\CVI_ecc_includes_60881.rsp -D_CVI_=1200 -D_NI_i386_=1 -D_NI_mswin_=1 -D_NI_mswin32_=1 -D_CVI_EXE_=1 -D_LINK_CVIRTE_=1 -D_CVI_FDS_=1 -D_CVI_USE_FUNCS_FOR_VARS_=1 -D__DEFALIGN=8 -D_NI_VC_=220 -D_WIN32=1 -DWIN32=1 -D__WIN32__=1 -D_WINDOWS=1 -D__NT_

 "Guiddef.h"(39,1)   :39:2: current parser token 'ifndef'

1, 1   Compile in external compiler failed.

 

Other complaints:

 

 "WTypes.h"(553,1)   :553:2: current parser token 'ifndef'

 

 "driverspecs.h"(342,1)   :342:3: current parser token 'ifndef'

 "RpcDce.h"(38,1)   :38:2: current parser token 'ifndef'

 

Looking at the given files I could not see anything unusual - but I never had been looking at these files before so I am not claiming to be of much help here Smiley Wink



May be somebody understands what is going on and can help me compiling my software in CVI2012 (it did work fine with previous releases of CVI...)

By the way, I also turned CVI99 extensions off, it did not change anything.

 

Thanks

0 Kudos
Message 1 of 13
(4,691 Views)

Hello Wolfgang,

 

thanks for your informative description about the compilation process in release mode.

 

Please do some tests for verifying the compilation in general:

 

1.Open an example in CVI 2010 and save this example with a unique specified filename.

2. Compile this projcet in CVI2012 as debug version

3. Compile the updated project as release version

 

Furthermore, please let me know, which operating system is used.

 

Thanks.

 

RupiDo

0 Kudos
Message 2 of 13
(4,662 Views)

Hello RupiDo,

 

I am a bit skeptical about your suggested tests for I have upgraded from 2010 to 2012, meaning that I don't have CVI2010 installed anymore...

 

The described scenario happened on a XP system, but I will try and see how compilation goes on a Win7 system. This exercise may take some time as I will need to make sure that the ecc files etc. are identical.

 

 

 

0 Kudos
Message 3 of 13
(4,652 Views)

I can add that on the XP system I can successfully compile other projects using the same clang.ecc file, hence I would exclude issues due to the OS and I would also tend to exclude issues due to the ecc file.

0 Kudos
Message 4 of 13
(4,646 Views)

Hi Wolfgang,

 

Can you reproduce this crash every time that you compile this particular project? If so, is there some way that you could us the project, or some reduced version of it that still reproduces the problem?

 

The JIT debugger window is coming up because clang-cc.exe is an external process, and every time that some standalone process crashes, and Windows catches the exception, Windows will launch the registered debugger, which in your case is the CVI JIT debugger. Of course, it won't be of much help, since the CVI debugger is useful only for debugging CVI-built debuggable programs, which clang-cc.exe isn't.

 

Luis

0 Kudos
Message 5 of 13
(4,635 Views)

OK,

 

some further note: Because the crash appears only for certain source files, I have created a new project with one of these 'critical' source files, and all the required include files. In this test project with just one source file the compilation succeeds, i.e. the build output does not show any compilation warning / error (but of course many link errors).

 

If I compile the same file within the large project, clang crashes.

 

Any directions of how to localize the problem?

0 Kudos
Message 6 of 13
(4,632 Views)

Hey Luis,

 

what a nice coincidence...Smiley Happy

 

The good news is that I can reproduce the crash every time that I compile the project... I will transfer the project to my other computer running Win 7 to see if I can reproduce the issue there, too. If so, I will ftp you the project.

 

Thanks!

0 Kudos
Message 7 of 13
(4,631 Views)

Some progress:

 

On the other system (Win 7) everything compiled. Then I loaded the ecc file of the XP system, compiled again, and ... clang crashed:

 

clang-win7.png

 

So I am attaching the two ecc files that hopefully will allow you to localize the problem...

 

OK, no attachments due to your forum software, which complains that the attachment's content type (text/plain) does not match its file extension.

 

crash:

 

CMPLRNAME = clang 32bit

VALID_CFG = 1

DOPARSING = 1

OPT_LEVEL = 2

WARNLEVEL = 1

USERFLAGS =

OBJFORMAT = Msvc

COMPFLAGS = -triple i386-pc-win32 -emit-o -ffreestanding -fno-caret-diagnostics

C89_FLAGS = --std=gnu89

C99_FLAGS = --std=c99 -D _CVI_C99_EXTENSIONS_

COMPLPATH = c:\Program Files (x86)\National Instruments\CVI2012\bin\clang\clang-cc.exe

ENV_BATCH = c:\Program Files (x86)\National Instruments\CVI2012\bin\clang\clang.bat

ENV_OPTNS =

OBJ_TEMPL = -o $OBJECT

SRC_TEMPL = $SOURCE

DEF_TEMPL = -D$MACRO

DEFVTEMPL = -D$MACRO=$VALUE

INC_TEMPL = -I $PATH

OPT_FLAGS

No Optimizations = -O0

Optimize for Space = -Os

Optimize for Speed = -O2

END_FLAGS

WARNFLAGS

Disable Warnings = -w

Default Warnings = -Wall -Wno-unknown-pragmas

More Warnings = -Wall -Wextra -Wno-unknown-pragmas

END_FLAGS

__CEND___

 

ok:

 

CMPLRNAME = clang 2.9

VALID_CFG = 1

DOPARSING = 1

OPT_LEVEL = 2

WARNLEVEL = 1

USERFLAGS =

OBJFORMAT = Msvc

COMPFLAGS = -cc1 -triple i386-pc-win32 -D_M_IX86=400 -emit-obj -ffreestanding -fms-extensions -mms-bitfields -fno-caret-diagnostics

C89_FLAGS = -std=gnu89

C99_FLAGS = -std=c99

COMPLPATH = c:\program files (x86)\national instruments\cvi2012\bin\clang\2.9\clang.exe

ENV_BATCH = c:\program files (x86)\national instruments\cvi2012\bin\clang\2.9\clang.bat

ENV_OPTNS =

OBJ_TEMPL = -o $OBJECT

SRC_TEMPL = $SOURCE

DEF_TEMPL = -D$MACRO

DEFVTEMPL = -D$MACRO=$VALUE

INC_TEMPL = -I $PATH

OPT_FLAGS

No Optimizations = -O0

Optimize for Space = -Os

Optimize for Speed = -O2

END_FLAGS

WARNFLAGS

Disable Warnings = -w

Default Warnings = -Wall -Wno-microsoft -Wno-unknown-pragmas

More Warnings = -Wall -Wextra -Wno-microsoft -Wno-unknown-pragmas -fdiagnostics-show-option

END_FLAGS

__CEND___

 

 

0 Kudos
Message 8 of 13
(4,623 Views)

As a final test, I have used the 'OK' ecc file on the XP system, and now here everything works OK, too.

 

So, here is my summary:

 

  • The crash is due to a combination of source files and ecc file: The 'critical' compiler settings alone do work for other projects, and the 'critical' project works with a different ecc file.

 

  • The 'OK' ecc file is based on the 2.9 template, while my original ecc file was inherited from earlier CVI versions, i.e. from the clang 1.0 version

 

  • It is a pity that a wrong configuration file can crash the compiler.

 

  • It is a pity that there are no release notes advising the user to change/update the compiler settings.

 

0 Kudos
Message 9 of 13
(4,609 Views)

I don't mind investigating the reason for the crash, but if it happens as a result of a combination of a bad config file with specific source files, then I'd still need to have those source files to find out what's going on. If you'd like to pursue this further, would you be able to upload one of those files/projects to our ftp server?

 

Concerning the clang documentation, in the post where I explained our rationale for rejecting that suggestion I also linked to the site that documents all those options. How would a CVI version of this documentation (plus an equivalent set for the Intel compiler, the Borland compiler, the MSVC compiler) be an improvement over this?

 

Luis

0 Kudos
Message 10 of 13
(4,592 Views)