09-06-2012 02:21 AM
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:
While still reading the message, CVI got impatient with me:
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:
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:
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
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
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
09-10-2012 07:49 AM
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
09-10-2012 03:18 PM
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.
09-11-2012 01:58 AM
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.
09-11-2012 10:00 AM
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
09-11-2012 10:02 AM
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?
09-11-2012 10:05 AM
Hey Luis,
what a nice coincidence...
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!
09-11-2012 01:19 PM - edited 09-11-2012 01:23 PM
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:
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___
09-12-2012 03:21 AM
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:
09-12-2012 01:50 PM
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