Bugzilla – Full Text Bug Listing
| Summary: | [type hierarchy] NullPointerException after closing type hierarchy view after a cancel | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Eddie Galvez <egalvez> | ||||
| Component: | UI | Assignee: | Raksha Vasisht <raksha.vasisht> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, ed, markus.kell.r | ||||
| Version: | 3.7 | Flags: | markus.kell.r:
review+
|
||||
| Target Milestone: | 3.7.1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Eddie Galvez
Probably not for 3.7.1. SR1 surely. It looks like a simple guard check. I'm seeing this too. But it's much more prolific. Every time I try to to run a Junit test, I get a load of these errors, and I think a load of wasted CPU time too. I'm not sure quite what triggered it, but I do have a sick Type Hierarchy view (displaying the initial select a type instruction). I may be seeing a greater problem because I'm getting an NPE from each of my 8 hierarchies. I've seen it before but blamed it on something else then. I actually get 70-odd error log entries per JUnit run and a couple per JDT editor incremental build. Very irritating having to close a pop-up every couple of editor actions. Closing the Type Hierarchy in _all_ perspectives stops the errors. Edward, it would be good to have exact steps that allow us to reproduce what you see. I cannot recall all the debugging actions I used. I was certainly using the Type Hierarchy view and may have got bored while some hierarchy such as Iterable was taking too long and so changed views and caused concurrent activity. However my observations of the inconvenience would suggest that a) some variable clearly can be null in an unexpected way and that can be guarded in the code. b) type hierarchies are being recomputed too aggressively; minor JDT edits should not provoke major activity; in particular, prior to a Save, should the hierarchy update at all. b) may be related to an undiagnosed problem whereby the builder appears to do repeated full builds in conjunction with some of Acceleo, Xtext, Papyrus, Modisco. Something is certainly triggering something else to do much much more than is desirable. I didn't see an obvious code path where fHierarchy.getInputElement() would be null. However, in 3.6, the line in HierarchyLabelProvider.getImage(..) looked like this, and thus contained an implicit null check:
if (element.equals(fHierarchy.getInputElement())) {
We should restore that for 3.7.1.
Raksha, please open a call hierarchy on TypeHierarchyLifeCycle#fInputElements and then prepare a patch that fixes all places where null checks and equals(..) tests have not been converted properly when we changed
IJavaElement fInputElement;
to
IJavaElement[] fInputElements;
E.g. in TypeHierarchyLifeCycle#doHierarchyRefresh(..), we use "elements.equals(fInputElements)" in 3.7, which doesn't make sense for arrays.
Created attachment 201216 [details] Patch (In reply to comment #6) Added null checks after calls to fHierarchy.getInputElement() > "elements.equals(fInputElements)" in 3.7, which doesn't make sense for arrays. Yep, replaced equals with Array.equals(..). Markus, could you pls review? TIA. Patch looks good. It looks like this got committed to HEAD. (In reply to comment #9) > It looks like this got committed to HEAD. Yes. Also committed to R3_7_maintenance branch. Released into R3_7_maintenance. Available in M20110817-0800. Verified in M20110824-0800 by code inspection and by trying various scenarios with multiple inputs and cancelling. |