Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316141

Summary:	build path validation marker removed by JDT listener during build.
Product:	[Eclipse Project] JDT	Reporter:	Joef Huang <joefh>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	gdtaylor, green, joefh, Olivier_Thomann
Version:	3.4.2	Keywords:	needinfo
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Joef Huang

2010-06-08 10:30:20 EDT

Build Identifier: M20090211-1700


We have a customer who gets different number of build path errors when using auto-build vs manual build. 

In the first case, this code creates the invalid classpath marker:
Thread [Worker-14] (Suspended (breakpoint at line 639 in Resource))	
	Project(Resource).createMarker(String) line: 639	
	JavaProject.createClasspathProblemMarker(IJavaModelStatus) line: 805	
	ClasspathValidation.validate() line: 73	
	DeltaProcessor.resourceChanged(IResourceChangeEvent) line: 1969	
	DeltaProcessingState.resourceChanged(IResourceChangeEvent) line: 431	
	NotificationManager$2.run() line: 288	
	SafeRunner.run(ISafeRunnable) line: 37	
	NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 282	
	NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148	
	Workspace.broadcastBuildEvent(Object, int, int) line: 297	
	AutoBuildJob.doBuild(IProgressMonitor) line: 136	
	AutoBuildJob.run(IProgressMonitor) line: 238	
	Worker.run() line: 55	

Debugging a bit further, I could see that this listener was stripping off the invalid classpath marker after it was created, thus leading to the exception in the Java Builder:
Thread [Worker-18] (Suspended)	
	LaunchingPlugin.resourceChanged(IResourceChangeEvent) line: 754	
	NotificationManager$2.run() line: 288	
	SafeRunner.run(ISafeRunnable) line: 37	
	NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 282	
	NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148	
	Workspace.broadcastBuildEvent(Object, int, int) line: 297	
	AutoBuildJob.doBuild(IProgressMonitor) line: 136	
	AutoBuildJob.run(IProgressMonitor) line: 238	
	Worker.run() line: 55	

The problem is that there are two pre-build listeners.  One is adding the build path validation marker, and the other one takes it away.  The validation marker is needed by the builder, so there is either an ordering issue or the second listener shouldn't be deleting the marker.



Reproducible: Always

Steps to Reproduce:
1. Launch workbench
2. Enable auto-build
3. Import the projects
4, Wait until build completes, get x number of build path errors
5, Start another workbench
6, Disable auto-build
7, Import the projects, and wait until it settles
8, Start a manual build
9, Wait until build completes, and get y number of build path errors.
10, Found x doesn't equal to y

Expected result:
x should equal to y.

Comment 1 Olivier Thomann

2010-06-15 14:28:13 EDT

Where can we get the projects to load ?

Comment 2 Grant Taylor

2010-06-15 14:32:46 EDT

Note that we couldn't reproduce this behaviour using pure Java projects, but only with our product's projects which have the JDT nature.  We not ruling out that something in our product stack is running when it's not supposed to or at a time when JDT doesn't appreciate it.  Can you give us a clue what would trigger this stack:
Thread [Worker-18] (Suspended)    
    LaunchingPlugin.resourceChanged(IResourceChangeEvent) line: 754    
    NotificationManager$2.run() line: 288    
    SafeRunner.run(ISafeRunnable) line: 37    
    NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[],
IResourceChangeEvent, boolean) line: 282    
    NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent,
boolean) line: 148    
    Workspace.broadcastBuildEvent(Object, int, int) line: 297    
    AutoBuildJob.doBuild(IProgressMonitor) line: 136    
    AutoBuildJob.run(IProgressMonitor) line: 238    
    Worker.run() line: 55  

Perhaps this will give us a hint at where to look to better identify where the problem lay (whether it be our product code or JDT).

Comment 3 Olivier Thomann

2010-10-30 11:34:44 EDT

This stack is triggered when a build starts and the resources that have changed since last build are processed.
We must either get more details on how to reproduce this issue or this will be closed as WORKSFORME.

Comment 4 Eclipse Genie

2020-04-13 17:49:35 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.