Bug 58679 - Regression from 1.1: NPE in CompilationResult
Summary: Regression from 1.1: NPE in CompilationResult
Status: RESOLVED DUPLICATE of bug 57432
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.2   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Jim Hugunin CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-15 12:12 EDT by Per S Hustad CLA
Modified: 2004-05-13 05:12 EDT (History)
1 user (show)

See Also:


Attachments
Contains one class file that 'fixes' this bug. (3.86 KB, application/x-zip-compressed)
2004-04-20 04:21 EDT, Andrew Clement CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Per S Hustad CLA 2004-04-15 12:12:36 EDT
We are using AspectJ on a large java project (ca 6000 classes) and have been 
running ajc 1.1 steadily for nearly a year - with no serious problems. 
When testing out the new 1.2 rc1 candidate, the following NPE ocurred:


ABORT
        
Exception thrown from AspectJ 1.2rc1

This might be logged as a bug already -- find current bugs at
  http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler

Bugs for exceptions thrown have titles File:line from the top stack, 
e.g., "SomeFile.java:243"

If you don't find the exception below in a bug, please add a new bug
at http://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ

To make the bug a priority, please include a test program
that can reproduce this exception.
null
java.lang.NullPointerException
        at org.eclipse.jdt.internal.compiler.CompilationResult.computePriority
(CompilationResult.java:110)
        at org.eclipse.jdt.internal.compiler.CompilationResult.quickPrioritize
(CompilationResult.java:336)
        at org.eclipse.jdt.internal.compiler.CompilationResult.getProblems
(CompilationResult.java:230)
        at org.eclipse.jdt.internal.compiler.CompilationResult.getAllProblems
(CompilationResult.java:118)
        at org.aspectj.ajdt.internal.core.builder.AjBuildManager$4.acceptResult
(AjBuildManager.java:661)
        at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.acceptResult
(AjCompilerAdapter.java:178)
        at org.aspectj.ajdt.internal.compiler.WeaverAdapter.finishedWith
(WeaverAdapter.java:203)
        at org.aspectj.ajdt.internal.compiler.WeaverAdapter.weaveCompleted
(WeaverAdapter.java:167)
        at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:570)
        at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.weave
(AjCompilerAdapter.java:239)
        at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.afterCompiling
(AjCompilerAdapter.java:114)
        at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:376)
        at 
org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation
(AjBuildManager.java:600)
        at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild
(AjBuildManager.java:160)
        at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild
(AjBuildManager.java:94)
        at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:102)
        at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:53)
        at org.aspectj.tools.ajc.Main.run(Main.java:280)
        at org.aspectj.tools.ajc.Main.runMain(Main.java:217)
        at org.aspectj.tools.ajc.Main.main(Main.java:79)


1 fail|abort
Comment 1 Andrew Clement CLA 2004-04-19 03:35:09 EDT
This is likely to be related to bug 57432.  If it is what I think it is then 
the problem is that you are having >100 errors/warnings (possibly declare 
errors/warnings) for some input files - is that possible? (And is this a 
binary weave?)
Comment 2 Per S Hustad CLA 2004-04-19 04:29:43 EDT
Correct. There are probably > 100 warnings generated. And it is a binary weave.
Comment 3 Andrew Clement CLA 2004-04-19 04:39:06 EDT
phew... so I do know what I'm doing :)

We go into the code that NPEs if there are >100 errors - the code is intended 
to throw away all but the most important 100 errors.

There are two options for 1.2 final:

- Disturb the codebase quite a lot adding support for binary source reference 
contexts.  This will make the code that determines the top 100 errors work 
successfully.

- Increase the number from 100 to something like 100000 - that will mean it is 
highly unlikely we'll ever trigger the prioritization logic.  We'll also leave 
the bug open and fix it properly in the next release.
Comment 4 Jim Hugunin CLA 2004-04-19 12:27:50 EDT
I like your idea of increasing the max errors given the fact that this is 
coming after 1.2rc1.  You should increase it to Integer.MAX or something 
similar to make sure it really won't show up in practice.
Comment 5 Andrew Clement CLA 2004-04-20 04:19:30 EDT
Ok, I've made the change, instead of the limit 
being 'compiler.options.maxProblemsPerunit', it is 'Integer.MAX_VALUE'.  
The line I fixed is in AjCompilerAdapter.getBinarySourcesFrom().  Its marked
XXX and with this bug number.

All the tests have passed.  I could respin a whole build and upload it 
somewhere for Per to try but as its such a localized change and I'm 
99.99999999% confident it is the fix for this bug, I'm about to attach a zip 
file to this bug report that contains the fix (a single .class file) - can you 
try this for me Per?  Easiest way is to put patch.zip ahead of 
aspectjtools.zip in the ajc.bat file and then attempting your binary weave.

Let me know if it works for you and we'll decide whether to cut a new RC 
containing the fix.
Comment 6 Andrew Clement CLA 2004-04-20 04:21:31 EDT
Created attachment 9681 [details]
Contains one class file that 'fixes' this bug.
Comment 7 Andrew Clement CLA 2004-04-23 08:41:32 EDT
I have created a new testcase for this.  A program that is subject to a binary 
weave and has 101 declare errors attached to it.  In AspectJ without the fix, 
the testcase fails with an NPE.  I have also checked in the fix to up the 
limit to Integer.MAX_VALUE.  We should now change this bug report to an 
enhancement.  The future enhancement would be to correctly support binary 
reference contexts for 'binary source' files (then the prioritization logic 
would not NPE).  I've marked the place in the code where Integer.MAX_VALUE is 
used - search for this bug number in the source.
Comment 8 Adrian Colyer CLA 2004-05-13 05:12:24 EDT

*** This bug has been marked as a duplicate of 57432 ***