Bug 311048 - AbortCompilation propagated from CompilationUnitProblemFinder.process()
Summary: AbortCompilation propagated from CompilationUnitProblemFinder.process()
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: Other All
: P3 normal (vote)
Target Milestone: 3.6 RC1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-29 11:46 EDT by Stephan Herrmann CLA
Modified: 2010-05-17 03:33 EDT (History)
4 users (show)

See Also:
srikanth_sankaran: review+


Attachments
source file for line number lookup (13.53 KB, text/x-java)
2010-04-29 15:23 EDT, Stephan Herrmann CLA
no flags Details
Proposed fix (6.21 KB, patch)
2010-04-29 15:25 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2010-04-29 11:46:53 EDT
My logs show AbortCompilation wrapped in a JavaModelException although the
initial exception was only meant to cause cancellation of the current operation
(from CancelableProblemFactory).

Inspecting the source of CompilationUnitProblemFinder the following block seems
inconsistent:

	if (parser != null) {
		problemFinder.parser = parser;
		try {
			unit = parser.parseCompilationUnit(unitElement, true/*full parse*/, monitor);
			problemFinder.resolve(
				unit,
				unitElement,
				true, // verify methods
				analyzeAndGenerateCode, // analyze code
				analyzeAndGenerateCode); // generate code
		} catch (AbortCompilation e) {
			problemFinder.handleInternalException(e, unit);
		}
	} else {
		unit =
			problemFinder.resolve(
				unitElement,
				true, // verify methods
				analyzeAndGenerateCode, // analyze code
				analyzeAndGenerateCode); // generate code
	}

Why is AbortCompilation only caught on one branch and not the other?
Looks like a bug to me.

I'm not sure how much effort it would be to extract a test case, but maybe
you agree that it is safe to just flip the nesting of try and if?
Comment 1 Olivier Thomann CLA 2010-04-29 12:16:49 EDT
This indeed looks like a bug.
Could you please give the complete log?
Comment 2 Stephan Herrmann CLA 2010-04-29 15:23:18 EDT
Created attachment 166555 [details]
source file for line number lookup

(In reply to comment #1)
> This indeed looks like a bug.
> Could you please give the complete log?

Sure, but it comes with my usual disclaimer: line numbers may be slightly off,
because this was taken from our jdt.core branch. I've attached our version
of CompilationUnitProblemFinder.java for line-number lookup.

Here's a typical stack trace:

Java Model Exception: org.eclipse.jdt.internal.compiler.problem.AbortCompilation:
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:260)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:281)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
        at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
        at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
        at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1274)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
        at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
        at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102)
        at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
        at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
Caused by: org.eclipse.jdt.internal.compiler.problem.AbortCompilation:
        at org.eclipse.jdt.internal.core.CancelableProblemFactory.createProblem(CancelableProblemFactory.java:30)
        at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.createProblem(ProblemHandler.java:80)
        at org.eclipse.jdt.internal.compiler.Compiler.handleInternalException(Compiler.java:651)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1000)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1036)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:220)
        ... 23 more
Caused by: org.eclipse.jdt.internal.compiler.problem.AbortCompilation:
        at org.eclipse.jdt.internal.core.CancelableProblemFactory.createProblem(CancelableProblemFactory.java:30)
        at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.createProblem(ProblemHandler.java:80)
        at org.eclipse.jdt.internal.compiler.Compiler.handleInternalException(Compiler.java:651)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1000)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1036)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:220)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:281)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
        at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
        at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
        at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1274)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
        at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
        at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102)
        at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
        at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)


Looking at Compiler.handleInternalException() there was an exception as the
root cause which is unfortunately not exposed in the logs.
However, any call to createProblem() after the monitor was canceled should 
cause the same effect.

HTH.
Comment 3 Olivier Thomann CLA 2010-04-29 15:25:56 EDT
Created attachment 166557 [details]
Proposed fix
Comment 4 Stephan Herrmann CLA 2010-04-29 15:40:28 EDT
Patch looks good to me.

Searching for the root cause, I came to the conclusion that I must have
had a RuntimeException during compilation, which was wrapped in an 
AbortCompilation and never unwrapped again. With your patch in place
I should be able to see my original bug :)
Comment 5 Olivier Thomann CLA 2010-05-03 09:35:04 EDT
Srikanth, please review.
Comment 6 Srikanth Sankaran CLA 2010-05-04 02:30:00 EDT
Patch looks good.
Comment 7 Olivier Thomann CLA 2010-05-04 10:04:01 EDT
Released for 3.6RC1.
Thanks again, Stephan.
Comment 8 Stephan Herrmann CLA 2010-05-04 10:47:43 EDT
(In reply to comment #7)
> Released for 3.6RC1.
> Thanks again, Stephan.

Thank you!
:)
Comment 9 Ayushman Jain CLA 2010-05-17 03:31:14 EDT
Verified for 3.6RC1 through code inspection.
Comment 10 Jay Arthanareeswaran CLA 2010-05-17 03:33:46 EDT
Verified.