Community
Participate
Working Groups
An error occurred while traversing resources. java.lang.IllegalArgumentException: ProducerArgument not null!!! at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildResource.addToArg(BuildResource.java:120) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildIOType.addResource(BuildIOType.java:64) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription.addOutputs(BuildDescription.java:950) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription.calculateOutputs(BuildDescription.java:1232) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription.composeOutputs(BuildDescription.java:636) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription.access$1(BuildDescription.java:531) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription$RcVisitor.doVisitFile(BuildDescription.java:224) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription$RcVisitor.visit(BuildDescription.java:154) at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85) at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription.initDescription(BuildDescription.java:725) at org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription.init(BuildDescription.java:748) at org.eclipse.cdt.managedbuilder.internal.buildmodel.DefaultBuildDescriptionFactory.createBuildDescription(DefaultBuildDescriptionFactory.java:37) at org.eclipse.cdt.managedbuilder.buildmodel.BuildDescriptionManager.createBuildDescription(BuildDescriptionManager.java:95) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.invokeInternalBuilder(CommonBuilder.java:882) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.invokeBuilder(CommonBuilder.java:1583) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:748) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:510) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:479) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:163) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:248) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:251) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:216) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:358) at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:494) at org.eclipse.core.internal.resources.Project.build(Project.java:75) at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:194) at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:141) at org.eclipse.ui.actions.WorkspaceAction$1.runInWorkspace(WorkspaceAction.java:460) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) eclipse.buildId=I20070323-1616 java.version=1.5.0_06 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -startup /opt/eclipse2/plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar Command-line arguments: -os linux -ws gtk -arch x86 -startup /opt/eclipse2/plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar
What CDT build are you using? According to the stack trace, the error has occured in Internal Builder while building the project. Could you provide some more detailed steps to reproduce the bug and/or a sample project that exposes this behavior? Thanks, Mikhail
I was using latest milestone, now tried latest nightly cdt build and issue is stil there. Building using external builder is fine. I cannot provide a quick way to reproduce yet.. project is rather complex and haven't been able to reproduce it otherwise. (In reply to comment #1) > What CDT build are you using? > > According to the stack trace, the error has occured in Internal Builder while > building the project. > Could you provide some more detailed steps to reproduce the bug and/or a sample > project that exposes this behavior? > > Thanks, > Mikhail >
I can reproduce this problem for the case there are two files included in the build having same name and different extensions, residing in one folder, e.g. foo.c and foo.cpp. This is the old MBS issue, i.e. neither the GNU makefile generator used for the external make builder nor the Internal Builder can handle this case. More than that the Internal Builder behaves behaves more correct in this case, i.e. it fails, while the GNU makefile generator sielently procedes and can generate wrong/inclomplete binary. The reason for the issue is that by default it is assumed that the output file for the <name>.<input_extension> file is the <name>.<output_extension> file. So in in case we have e.g. foo.c and foo.cpp files in one directory the generated file for both of them will be foo.o for the gnu tool-chain. Now suppose the foo.c is built first and the foo.o is created. After that foo.cpp is built. the foo.o gets overwritten. The resulting binary will include include only foo.o created from the foo.cpp Could you check whether this is your case or not (i.e. there are buildable files with the same name and different extensions residing in one folrer in your project)? Thanks, Mikhail
There are no *.c and *.cpp equivalents, however, there are multiple identically named files foo.cpp (2x) and foo2.h (2x) in different directories. Could that explain the problem ?
