Eclipse (Juno) CDT indexer: "Error while parsing..." a Makefile project - c++

I am working on a clone of this Github project in Eclipse CDT and I haven't managed to create an error-free index of it (an example of the error log is given below for AncSplit.cpp). All the CPU resources (Intel® Core™ i7 CPU X 940 # 2.13GHz × 8 with 8Gb RAM) are taken up for a while and parsing errors are generated for every .cpp and .h file in the project.
In order to reproduce/identify the problem I only kept the source files and the the customized project Makefile in a single folder. I also removed Eclipse (and workspace preferences...) and reinstalled it from scratch.
N.B. I also made the following changes -Xms1G, -Xmx2G and -XX:MaxPermSize=1G in the eclipse.ini file in order to bypass insufficient heap space related problems.
I am using Eclipse :
Version: Juno Service Release 1
Build id: 20121004-1855
Thanks in advance.
!SESSION 2012-12-12 23:44:47.084 -----------------------------------------------
eclipse.buildId=M20120914-1800
java.version=1.7.0_10
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.cpp.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.cpp.product
!ENTRY org.eclipse.cdt.core 4 0 2012-12-13 00:07:02.918
!MESSAGE Error while parsing /lagrange/AncSplit.cpp.
!STACK 0
java.lang.NullPointerException
at org.eclipse.cdt.internal.core.dom.parser.Value.isDependentValue(Value.java:373)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.isDependentArgument(CPPTemplates.java:2323)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.hasDependentArgument(CPPTemplates.java:2313)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiate(CPPTemplates.java:181)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiate(CPPTemplates.java:166)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveDeferredClassInstance(CPPTemplates.java:2468)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveUnknown(CPPTemplates.java:2393)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateType(CPPTemplates.java:1173)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveUnknown(CPPTemplates.java:2401)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateType(CPPTemplates.java:1173)
at org.eclipse.cdt.internal.core.dom.parser.cpp.AbstractCPPClassSpecializationScope.getBases(AbstractCPPClassSpecializationScope.java:158)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPClassSpecialization.getBases(CPPClassSpecialization.java:219)
at org.eclipse.cdt.internal.core.dom.parser.cpp.ClassTypeHelper.getBases(ClassTypeHelper.java:243)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BaseClassLookup.lookupInBaseClass(BaseClassLookup.java:192)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BaseClassLookup.lookupInBaseClass(BaseClassLookup.java:235)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BaseClassLookup.lookupInBaseClasses(BaseClassLookup.java:54)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.lookup(CPPSemantics.java:983)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.resolveUnknownName(CPPSemantics.java:3679)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveUnknown(CPPTemplates.java:2425)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateType(CPPTemplates.java:1173)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateType(CPPTemplates.java:1223)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.TemplateArgumentDeduction.deduceFromFunctionArgs(TemplateArgumentDeduction.java:125)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.TemplateArgumentDeduction.deduceForFunctionCall(TemplateArgumentDeduction.java:88)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateForFunctionCall(CPPTemplates.java:1749)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateForFunctionCall(CPPTemplates.java:1728)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.resolveFunction(CPPSemantics.java:2363)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalFunctionSet.resolveFunction(EvalFunctionSet.java:187)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalFunctionCall.instantiate(EvalFunctionCall.java:202)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalUnary.instantiate(EvalUnary.java:281)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalBinary.instantiate(EvalBinary.java:343)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateValue(CPPTemplates.java:866)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.createSpecialization(CPPTemplates.java:786)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPClassSpecialization.specializeMember(CPPClassSpecialization.java:176)
at org.eclipse.cdt.internal.core.dom.parser.cpp.AbstractCPPClassSpecializationScope.getBindings(AbstractCPPClassSpecializationScope.java:116)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.getBindingsFromScope(CPPSemantics.java:1205)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.lookup(CPPSemantics.java:953)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalID.resolveName(EvalID.java:320)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalID.instantiate(EvalID.java:307)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalBinary.instantiate(EvalBinary.java:343)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalBinary.instantiate(EvalBinary.java:343)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateValue(CPPTemplates.java:866)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.createSpecialization(CPPTemplates.java:786)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPClassSpecialization.specializeMember(CPPClassSpecialization.java:176)
at org.eclipse.cdt.internal.core.dom.parser.cpp.AbstractCPPClassSpecializationScope.getBindings(AbstractCPPClassSpecializationScope.java:116)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.getBindingsFromScope(CPPSemantics.java:1205)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.lookup(CPPSemantics.java:953)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalID.resolveName(EvalID.java:320)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalID.instantiate(EvalID.java:307)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateValue(CPPTemplates.java:866)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateArgument(CPPTemplates.java:1079)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateArguments(CPPTemplates.java:1053)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveDeferredClassInstance(CPPTemplates.java:2447)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveUnknown(CPPTemplates.java:2393)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateType(CPPTemplates.java:1173)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.resolveUnknown(CPPTemplates.java:2401)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPTemplates.instantiateType(CPPTemplates.java:1173)
at org.eclipse.cdt.internal.core.dom.parser.cpp.AbstractCPPClassSpecializationScope.getBases(AbstractCPPClassSpecializationScope.java:158)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPClassSpecialization.getBases(CPPClassSpecialization.java:219)
at org.eclipse.cdt.internal.core.dom.parser.cpp.ClassTypeHelper.getBases(ClassTypeHelper.java:243)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.SemanticUtil.inheritanceClosure(SemanticUtil.java:153)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.SemanticUtil.getConversionOperators(SemanticUtil.java:129)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BuiltinOperators.getClassConversionTypes(BuiltinOperators.java:669)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BuiltinOperators.arithmeticAssignement(BuiltinOperators.java:487)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BuiltinOperators.create(BuiltinOperators.java:195)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.BuiltinOperators.create(BuiltinOperators.java:68)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.findOverloadedOperator(CPPSemantics.java:3383)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.findOverloadedBinaryOperator(CPPSemantics.java:2992)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalBinary.computeOverload(EvalBinary.java:242)
at org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.EvalBinary.getOverload(EvalBinary.java:224)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTBinaryExpression.getOverload(CPPASTBinaryExpression.java:262)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTBinaryExpression.getImplicitNames(CPPASTBinaryExpression.java:131)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTBinaryExpression.accept(CPPASTBinaryExpression.java:164)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTExpressionStatement.accept(CPPASTExpressionStatement.java:73)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTCompoundStatement.accept(CPPASTCompoundStatement.java:85)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTIfStatement.accept(CPPASTIfStatement.java:145)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTCompoundStatement.accept(CPPASTCompoundStatement.java:85)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTIfStatement.accept(CPPASTIfStatement.java:145)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTCompoundStatement.accept(CPPASTCompoundStatement.java:85)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTFunctionDefinition.accept(CPPASTFunctionDefinition.java:201)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTTemplateDeclaration.accept(CPPASTTemplateDeclaration.java:127)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTNamespaceDefinition.accept(CPPASTNamespaceDefinition.java:139)
at org.eclipse.cdt.internal.core.dom.parser.ASTTranslationUnit.accept(ASTTranslationUnit.java:251)
at org.eclipse.cdt.internal.core.pdom.PDOMWriter.extractSymbols(PDOMWriter.java:444)
at org.eclipse.cdt.internal.core.pdom.PDOMWriter.addSymbols(PDOMWriter.java:225)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.writeToIndex(AbstractIndexerTask.java:1170)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.parseFile(AbstractIndexerTask.java:1007)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.parseLinkage(AbstractIndexerTask.java:828)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.runTask(AbstractIndexerTask.java:508)
at org.eclipse.cdt.internal.core.pdom.indexer.PDOMIndexerTask.run(PDOMIndexerTask.java:139)
at org.eclipse.cdt.internal.core.pdom.indexer.PDOMRebuildTask.run(PDOMRebuildTask.java:87)
at org.eclipse.cdt.internal.core.pdom.PDOMIndexerJob.run(PDOMIndexerJob.java:137)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Figured it out, it was indeed a bug (and I have filed one).
A colleague of mine managed to flawlessly index the Github project which resulted in :
Indexed 'src' (20 sources, 1,061 headers) in 43.46 sec: 86,471 declarations; 231,728 references; 0 unresolved inclusions; 12 syntax errors; 592 unresolved names (0.19%)
He was on a Fedora distribution with its default package of Eclipse Juno CDT. This meant that he was using :
Eclipse C/C++ Development Tools
Version: 8.1.0.201206111645
which is not quite the same as the standard Juno CDT download :
Eclipse C/C++ Development Tools
Version: 8.1.1.201209170703
I checked this workaround on my Ubuntu system (12.04 LTS) by installing Classic Juno along with CDT 8.1.0 and the indexing/parsing works all right now.

Related

platformio No such file or directory problem

So I wanted to create a project, but when I tried to add a simple header file (adp.h), use quick fix to add this line: "${workspaceFolder}/lib/boot/headers" to c_cpp_properties.json and build the project, builder does not even find this file.
It seems strange to me, because three days earlier, when I was using this method to add header files the builder was building my older projects flawlessly.
adp.h do not contain anything
editor setup
Building message:
Processing teensy41 (platform: teensy; board: teensy41; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/teensy/teensy41.html
PLATFORM: Teensy (4.12.0) > Teensy 4.1
HARDWARE: IMXRT1062 600MHz, 512KB RAM, 7.75MB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES:
- framework-arduinoteensy 1.153.0 (1.53)
- toolchain-gccarmnoneeabi 1.50401.190816 (5.4.1)
LDF: Library Dependency Finder -> http://bit .ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 90 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Compiling .pio\build\teensy41\src\main.cpp.o
Compiling .pio\build\teensy41\FrameworkArduino\AudioStream.cpp.o
Compiling .pio\build\teensy41\FrameworkArduino\Blink.cc.o
Compiling .pio\build\teensy41\FrameworkArduino\DMAChannel.cpp.o
src\main.cpp:2:17: fatal error: adp.h: No such file or directory
*************************************************************
* Looking for adp.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:adp.h"
* Web > https://platformio.org/lib/search?query=header:adp.h
*
*************************************************************
compilation terminated.

How to upload iOS app to Appstore which uses OpenCV [duplicate]

Compiling Xcode Project fails with following errors:
'missing required architecture arm64 in file /Users/*/Git/ocr/opencv2.framework/opencv2'
It works well, if i change Architectures(under Build Settings) to (armv7, armv7s) instead of (armv7, armv7s).
How to change the opencv python build script, to add arm64 support to opencv2.framework?
The latest OpenCV iOS framework supports 64 bit by default
It can be downloaded at: OpenCV download page
I modified the following to make it build, though I haven't got an arm64 iOS device to test at the moment.
Edit: I also had to follow https://stackoverflow.com/a/17025423/1094400
Assuming "opencv" is the folder containing the opencv source from Github:
in each of gzlib.c, gzread.c, gzwrite.c located in opencv/3rdparty/zlib/ add:
#include <unistd.h>
at the top after the existing include.
In addition open opencv/platforms/ios/cmake/Modules/Platform/iOS.cmake and change line 88 from:
set (CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_BIT)" CACHE string "Build architecture for iOS")
to:
set (CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_INCLUDING_64_BIT)" CACHE string "Build architecture for iOS")
Furthermore change the buildscript at opencv/platforms/ios/build_framework.py in lines 99 and 100 from:
targets = ["iPhoneOS", "iPhoneOS", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "i386"]
to:
targets = ["iPhoneOS", "iPhoneOS", "iPhoneOS", "iPhoneSimulator", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "arm64", "i386", "x86_64"]
The resulting library will include the following:
$ xcrun -sdk iphoneos lipo -info opencv2
Architectures in the fat file: opencv2 are: armv7 armv7s i386 x86_64 arm64
Although I have a remaining concern regarding opencv/platforms/ios/cmake/Toolchain-iPhoneOS_Xcode.cmake which defines the size of a data pointer to be 4 in lines 14 and 17.
It should be 8 for 64bit I guess, so as I haven't tested if the compiled library is working for arm64 I would suggest further investigations at this point if it does not run properly.
micahp's answer was almost perfect, but missed the simulator version. So modify platforms/ios/build_framework.py to:
targets = ["iPhoneOS", "iPhoneOS", "iPhoneOS", "iPhoneSimulator", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "arm64", "i386", "x86_64"]
You'll need to download the command line tools for Xcode 5.0.1 and then run
python opencv/platforms/ios/build_framework.py ios
Try to wait a next month. Will release a new XCode with more powerful supporting of 32/64 bit.
https://developer.apple.com/news/index.php?id=9162013a
Modify "build_frameworks.py" to:
def build_framework(srcroot, dstroot):
"main function to do all the work"
targets = ["iPhoneOS", "iPhoneOS", "iPhoneOS", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "arm64", "i386"]
for i in range(len(targets)):
build_opencv(srcroot, os.path.join(dstroot, "build"), targets[i], archs[i])
put_framework_together(srcroot, dstroot)
#Jan, I followed your instructions, but OpenCV still doesn't run on arm64. You made such a detailed and wonderful answer - why not check it out on a simulator and see if you can make it run? :-)
FWIW, I think it might be harder than it seems. On the openCV stackoverflow clone, there's an indication that this problem might be non-trivial.
Instead of using terminal commands given in the opencv installation guide in official website, use the following commands. Worked for me.
cd OpenCV-2.3.1
mkdir build
cd build
cmake -G "Unix Makefiles" ..
make
sudo make install
I was having a similar error, but the issue wasn't related with the arm64 coompilation.fixed adding the framework libc++.dylib

How to control the cl.exe command that nvcc builds

I just installed CUDA 6.5, VS2013 Community Edition, and pyCUDA. I already had python 2.7.8 installed. I am new to CUDA and VS2013 development but not python. I verified my CUDA install by building some of the CUDA VS2013 sample solutions as both 32- and 64-bit so things work up to that point.
Now I'm trying to verify my pyCUDA install by running this test program.
### from: http://documen.tician.de/pycuda/tutorial.html
import pycuda.gpuarray as gpuarray
import pycuda.driver as cuda
import pycuda.autoinit
import numpy as np
# copy to gpu
a_gpu = gpuarray.to_gpu(np.random.randn(4,4).astype(np.float32))
# double it
a_doubled = (2 * a_gpu).get()
print('a_doubled', a_doubled)
When run, it produces this error:
[snip]
File "B:\Anaconda2\lib\site-packages\pycuda-2014.1-py2.7-win-amd64.egg\pycuda\compiler.py", line 250, in do_compile
return compile_plain(source, options, keep, nvcc, cache_dir)
File "B:\Anaconda2\lib\site-packages\pycuda-2014.1-py2.7-win-amd64.egg\pycuda\compiler.py", line 132, in compile_plain
stderr=stderr.decode("utf-8", "replace"))
CompileError: nvcc compilation of e:\temp\cb4\tmpadhjeh\kernel.cu failed
[command: nvcc -cubin -keep -cudart shared -arch sm_52 -m64 -Ib:\anaconda2\lib\site-packages\pycuda-2014.1-py2.7-win-amd64.egg\pycuda\cuda -keep kernel.cu]
[stdout:kernel.cu]
[stderr:
'B:\VisualStudioCom2013\VC\bin\amd64"\cl.exe #kernel.cpp1.ii.res > "kernel.cpp1.ii' is not recognized as an internal or external command,
operable program or batch file.]
Note the extraneous double quotes in the cl.exe command which are causing the error. Without them I can manually run B:\VisualStudioCom2013\VC\bin\amd64\cl.exe #kernel.cpp1.ii.res > kernel.cpp1.ii. It completes just fine and a valid kernel.cpp1.ii is generated.
Is there some way to control the cl.exe command that nvcc builds? Nothing in the nvcc manual jumped out at me, but with all those options I certainly might've have missed it.
Also posted in this Nvidia developers forum.
This is a bug in nvcc for CUDA 6.5. After following #talonmies suggestion to look through nvcc.profile, I started trying combinations of profile settings and command line options. I narrowed it down to this: when --keep is on the command line AND compiler-bindir is in the nvcc.profile, the malformed cl.exe compile command that includes double quotes is generated. The solution for keeping intermediate files is to put cl.exe in the path and remove compiler-bindir from nvcc.profile. Logged as a bug to NVIDIA.
UPDATE:
The problem does not manifest in CUDA 7.0.

ASSIMP bulid error : "invalid option -f"

This is my first question here, and i'm not good at english, so be merciful :D
I am trying to build an ASSIMP library in Code::Blocks (MinGW compiler). I used CMake to generate C::B project (i haven't changed much apart from setting DirectX path and enabling BOOST workaround ).When i'm trying to build the project the library seems to build:
Build finished: 1 errors, 204 warnings (17 minutes, 25 seconds)
but i get an error :
=== Assimp, all ===
... (warnings)
invalid option -f
Enyone knows what seems to be the problem ?

Eclipse CDT crash randomly under Windows 7 x64?

I use the last JRE, Eclipse C++ package and Mingw. I can compile but Eclipse crash randomly in few minutes after it starts.
Log file :
eclipse.buildId=M20110210-1200
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=fr_FR
Framework arguments: -product org.eclipse.epp.package.cpp.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.cpp.product
!ENTRY org.eclipse.core.resources 2 10035 2011-03-11 20:08:04.087
!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.
!ENTRY org.eclipse.cdt.core 4 0 2011-03-11 20:19:20.164
!MESSAGE Error while parsing /TD1_Seq/src/main.cpp.
!STACK 0
java.lang.NullPointerException
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTTemplateId.accept(CPPASTTemplateId.java:162)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTCompositeTypeSpecifier.accept(CPPASTCompositeTypeSpecifier.java:153)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTSimpleDeclaration.accept(CPPASTSimpleDeclaration.java:89)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTTemplateSpecialization.accept(CPPASTTemplateSpecialization.java:73)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTNamespaceDefinition.accept(CPPASTNamespaceDefinition.java:116)
at org.eclipse.cdt.internal.core.dom.parser.ASTTranslationUnit.accept(ASTTranslationUnit.java:268)
at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTTranslationUnit.resolveAmbiguities(CPPASTTranslationUnit.java:173)
at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.resolveAmbiguities(AbstractGNUSourceCodeParser.java:664)
at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.parse(AbstractGNUSourceCodeParser.java:651)
at org.eclipse.cdt.core.dom.parser.AbstractCLikeLanguage.getASTTranslationUnit(AbstractCLikeLanguage.java:143)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.createAST(AbstractIndexerTask.java:285)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.createAST(AbstractIndexerTask.java:258)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.parseFile(AbstractIndexerTask.java:754)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.parseLinkage(AbstractIndexerTask.java:637)
at org.eclipse.cdt.internal.core.pdom.AbstractIndexerTask.runTask(AbstractIndexerTask.java:344)
at org.eclipse.cdt.internal.core.pdom.indexer.PDOMIndexerTask.run(PDOMIndexerTask.java:127)
at org.eclipse.cdt.internal.core.pdom.PDOMIndexerJob.run(PDOMIndexerJob.java:137)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I try to use option :
-vm "C:\Programs Files\java\bin\"
but eclipse still crash and no error is report in log file.
log file : http://pastebin.com/zEgQjmPq
This is this bug in the Java VM:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=333227
There are workarounds:
Add: -XX:-UseCompressedOops to your eclipse.ini
Use an JVM older that 1.6.0_23
Use a Java 7 VM
Use a VM other Sun JVM
On my machine (win 7 64, 1.6.0_24 JVM) eclipse CDT crashes every time when it tries to index a project. I've attempted to report a bug through help->report bug.., but CDT failed with some error again. I guess I will try netbeans)
Try to use JVM update 22, it resolved the problem.
This appears to be fixed in JDK 1.6.0_26