- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used C++ Composer XE 2011 update 6 with VS2010 on Windows 7 x64 platform. The compilation failed with the crash information "mcpcom.exe has stopped working" with the following details:
-----------------------------------------------------------------------------
Problem signature:
Problem Event Name: APPCRASH
Application Name: mcpcom.exe
Application Version: 0.0.0.0
Application Timestamp: 4e44b9af
Fault Module Name: StackHash_dd15
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 000000006fff03e8
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: dd15
Additional Information 2: dd152986fe395b5a883659aefed8eb71
Additional Information 3: af43
Additional Information 4: af43a00ee10606b603d5ffb3aac00165
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\\Windows\\system32\\en-US\\erofflps.txt
------------------------------------------------------------------------------
The build log is as follows:
------------------------------------------------------------------------------
1>------ Build started: Project: test, Configuration: Release x64 ------
1> main.c
1>
1> compilation aborted for ..\\src\\main.c (code -1073741819)
1>C:\\Program Files (x86)\\MSBuild\\Microsoft.Cpp\\v4.0\\Platforms\\x64\\PlatformToolsets\\Intel C++ Compiler XE 12.1\\Microsoft.Cpp.x64.Intel C++ Compiler XE 12.1.targets(211,5): error MSB6006: "icl.exe" exited with code -1073741819.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
-------------------------------------------------------------------------------
However, the compilation on Windows XP 32bit platform was successful.
Anyone have ideas on solving this problem?
Thanks,
Lee
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/Zi /nologo /W3 /O2 /Oi /Qipo /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /P /EHsc /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fp"x64\Release\test.pch" /Fa"x64\Release" /Fo"x64\Release" /Fd"x64\Release\vc100.pdb" /TC
I just added the /P and /TC to the default compiler options and the generated .i file was attached.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The entire project was attached.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your solution seems to be broken somehow because I cannot compile it using Intel Composer 2011 Update 7 as well.
Compilation with MSVC (both debug and release x64) work fine. If I recreate the solution then everything works fine.
The weird part is that there is virtually no difference between your project .vcxproj and .sln files and mine (apart from project GUID assigned)!
I can only suggest one thing, and that is to create a new solution to see if the problem goes away.
I would also like to note that when you create separate folder for a solution (so you can have multiple projects inside) it is not very logical to place the source code in the solution folder itself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Look there is an Access Violation exception in the log:
...
Exception Code: c0000005
Exception Offset: 000000006fff03e8
...
Also, there is an exit code -1073741819, and if you convert it from Radix10 to Radix16 you will get:
FFFFFFFFC0000005
Personally, I would report it asa bug in the icl.exe.
If some software subsystem in the compiler writes some datato a wrong memory address how could you solve it? There is only one way to solve it, that is,at the source codes level by Intel developers.
Best regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bugs in the code are sometimes not isolated to a single component -- they are a consequence of interactions between various components (in this case icl.exe and the VS2010 build system).
C000005 is a generic error code that indicates a stray pointer has been used to access (it can also be read, not only write) memory. But that bad pointer can be a result of another component and even a particular OS function which behaves differently in Windows 7 and in Windows XP for some reason known only to Microsoft developers.
He should most certainly file a bug with Premier support, but just reporting it without trying to create an isolated and reproducible test case will not allow Intel developers to fix it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recreated the solution and put the source code main.c outside the solution folder as you recommended. Unfortunately, the compilation still failed and the problem remained the same. Did the problem related with some broken components of x64 platform?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am unable toduplicate your compilation failure issue. Can youattach the projectlog file with environment variables? You can enable the environment variables through Tools >> Options >> Projects and Solutions >> VC++ Project Settings. Change the option for the "Show Environment in Log" to Yes thenrebuild your project. The test.log file should be located under your \test\test\x64\Release file directory.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When the failure happens does it showJust-In-Time Debugger window? Like:
What I wanted to suggest you need to attach the MS VS Debugger to an application, icl.exe or mcpcom.exe, somehow during the compilation process!
If you managed to do this you will be able to see some codes in a Dissasembly Window when an Access Violation happens.
Also, did you have a chance to look at a Windows' 'Minidump' folder? It is usually located in:
%SystemRoot%\Minidump
If you find some dumps related to your problem it is a good idea to forward them to Intel's developers.
Best regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
...
(211,5): error MSB6006: "icl.exe" exited...
...
Did you have a chance to search forerror MSB6006 on the Web? You will find lots of interesting stories!
Ilooked at some of them and I have a concern that it could beMicrosoft's problem rather than Intel'sbecause two Intel's developers couldn't reproduce the crash...
Lee,
some time ago Microsoft has released several Service Packs ( SPs )for MS Visual Studios ( 2005, 2008 and 2010 ) and lots of updatesfor different versions of .NET. Would you be able to check if your computerhas all Microsoft'supdates?
It is really hard to believe that you have that problem but who knows maybe that bug ( if this is a really Microsoft's bug )isalready fixed in one of these SPs orupdates.
Best regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it showed the Just-In-Time Debugger window. The Disassembly information was attached.
I checked the Minidump folder and there was no dump files in it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lee,
From your log it looks like compiler is again getting a relative path for the C file (..\..\main.c). It does not look like the source file is in the right place in the hierarchy.
What I suggested was:
TEST <- solution dir
|
+ TEST <- project dir
|
+ SRC <- source dir for project
|
+ main.c
The path compiler is getting in the command line should be something like .\test\test\src\main.c in that case.
Can you please also try creating a new project without creating a separate solution folder (i.e. leave the option unchecked) and keep the source in the main folder just like it is usually done? I would like to eliminate folder hierarchy as a possible cause.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, here is some summary:
1. The crash happens in mcpcom.exe application and it belongs to Intel, right?
2. Intel's software developers claimed that they couldn't reproduce the problem;
3. I just found that a similar mcpcom problem happened in 2005 for a Linux version of Intel's compiler:
http://software.intel.com/en-us/forums/showthread.php?t=46743
Please follow the link because there are a couple of useful comments;
4.When the crash happens:
- attach a VS Debugger to aworking copy of VS;
- then open a Disassembly window and look for some function names a couple of code-pages up
and down( PgUp &PgDn );
- since mcpcom.exe is a Release version you won't see to much, but you could find some names or
labelsand it could help to understand the problem;
5. Also, regarding a comment andconcern about a relative path to 'main.c' file. Try to rename 'main.c' to 'main.1.c'in Windows Explorer ( not in VS! )but keep the original name in VS and see what happens. If VS & ICC & your projectare properly configured your error message could look like:
Cannot open source file: '.\main.c': No such file or directory
and ifit still craches follow the instruction #4...6. Try to change 'Output verbosity' setting:
Good luck!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
...
I finally could solve the problem, so I just would like to share this experience: looking at the logs on my system, I have seen a kernel message telling it had killed mcpcom, due to a huge memory consumption:
Feb 9 15:15:37 foo kernel: Out of Memory: Killed process 15204 (mcpcom).
So I simply added some extra swap, and everything went fine. Running some monitoring tool in parallel, I could see the compiler was using about 400 MB of memory.
...
PS: I would also check log records ina Windows Event Viewer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As you recommended, I created a new project test2 without separate solution folder, and put the main.c in the src folder under the main folder test2. The problem remained unsolved. I think that the problem might not be related to the folder hierarchy.
The whole project test2 and build log file test2.log were attached.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lee,
1. Did you try to increasesize of your Virtual Memory? ( for example, twice )
2.Did you do Windows Updates verfication?
3.Could you look at what is going on in aTask Manager when the crash happens?
4.Could you look at Events Log just right after the crash?
5.Do you have a DrWatson.exe application in a Windows folder? If Yes, start it, reproduce the crash, follow steps 3 and 4 please.
6. Do you have any Anti-Virus software installed. If Yes, disable it and try reproduce the crash, follow steps 3 and 4, again.
Some screenshoots from the Task Managerwould be very useful.
Igor, what do you think about the last resort - Reinstall MS Visual Studio?
Best regards,
Sergey
PS: Lee, thanks for updated Test projects. I've downloaded already and will look tonight.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please try these steps to confirm:
1. Launch Parallel Studio 2011->Command prompt->Intel 64 Visual Studio 2010 mode from the Start Menu
2. In the command prompt window type:
devenv /UseEnv
This command will launch Visual Studio instance which will inherit environment variables from the command prompt.
3. Load your solution and build it in x64 mode.
If it succeeds then the problem is with the incorrect or missing PATH setting for cross-compile binaries (C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64 and/or C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE are not in path).
If you still have problems, then there are two separate issues at play here.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page