This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | NullPointerException at org.netbeans.modules.refactoring.java.RetoucheUtils.getOverridingMethods | ||
|---|---|---|---|
| Product: | java | Reporter: | evan38109 <evan38109> |
| Component: | Source | Assignee: | Tomas Zezula <tzezula> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | aldobrucale, asmotrich, bburette, bkampers, cashannon, dbalek, dfa, gnewton, grimlock81, gtzabari, jdstroy, jglick, joaope, jonast, jpokorsky, juhrik, K__P, lanceb, lytles, matthies, michael.nischt, mikemaughan, mjr_1974, mmirilovic, nuttycom, parafacundo, paulby, peterwlynch, rgw21, rkamradt, rost, smsmithee, twolf2919, tzezula |
| Priority: | P2 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://statistics.netbeans.org/exceptions/detail.do?id=9948 | ||
| Issue Type: | DEFECT | Exception Reporter: | 9948 |
| Bug Depends on: | |||
| Bug Blocks: | 165732 | ||
| Attachments: |
stacktrace
stacktrace stacktrace stacktrace stacktrace stacktrace stacktrace stacktrace stacktrace stacktrace Message log ignore - just testing attachments (previous attempt for tar failed) Test upload binary files stacktrace var/log/messages.log stacktrace |
||
|
Description
evan38109
2007-10-31 05:06:48 UTC
Created attachment 52083 [details]
stacktrace
Build: NetBeans IDE Dev (Build 200710241200) VM: Java HotSpot(TM) Client VM, 1.6.0-b105 OS: Windows XP, 5.1, x86 User Comments: Tried refactoring using ctrl + r to rename a method Created attachment 52085 [details]
stacktrace
Build: NetBeans IDE Dev (Build 200710291200) VM: Java HotSpot(TM) Client VM, 1.6.0-b105 OS: Windows XP, 5.1, x86 User Comments: Used ctrl - r to try and refactor a method name Created attachment 52086 [details]
stacktrace
The refactoring takes ClassIndex from ClasspathInfo of the CompilationInfo inside a JavaSource task and looks for all implementors. It even checks if the found implementor is part of the ClasspathInfo. How is it possible that ElementHandle of the implementor resolves to null inside the same JavaSource task? Reassigning to java/source for evaluation. evan38109, would it be possible to attach sources or a simplified test case demonstrating the problem? It would help us to find what is going wrong. Thanks. *** Issue 124751 has been marked as a duplicate of this issue. *** evan38109 confirmed, that this issue does not happen to him in latest builds. I'm reopening this because submitting error report number 18464 (http://statistics.netbeans.org/analytics/detail.do? id=18464) redirected me to this issue, claiming that it is fixed in 6.1M1. But the error happened for me with 6.1 Beta now. Product Version: NetBeans IDE 6.1 Beta (Build 200803050202) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) to matthies: Are you able to reproduce this issue? Can you provide a log file or project? Doesn't the error report include a log? Cleaning the cache and restarting the IDE solved the problem, so I can't reproduce it now. It contains just the exception not complete log. I will add logging into the refactoring, when it happens again the exception will contain more info. This issue has already 10 duplicates This issue has already 5 duplicates moving opened issues from TM <= 6.1 to TM=Dev Build: NetBeans IDE 6.0.1 (Build 200801291616) VM: Java HotSpot(TM) Client VM, 1.5.0_13-119 OS: Mac OS X, 10.5.2, i386 User Comments: I was attempting to rename a method in an abstract class. Created attachment 60443 [details]
stacktrace
Build: NetBeans IDE 6.1 (Build 200804211638) VM: Java HotSpot(TM) Client VM, 10.0-b22, Java(TM) SE Runtime Environment, 1.6.0_06-b02 OS: Windows XP, 5.1, x86 User Comments: wanted to refactor a method name on an interface Created attachment 61214 [details]
stacktrace
Build: NetBeans IDE 6.1 (Build 200804211638) VM: Java HotSpot(TM) Client VM, 10.0-b22, Java(TM) SE Runtime Environment, 1.6.0_06-b02 OS: Windows XP, 5.1, x86 User Comments: Created attachment 61215 [details]
stacktrace
Build: NetBeans IDE 6.1 (Build 200804211638) VM: Java HotSpot(TM) 64-Bit Server VM, 10.0-b19, Java(TM) SE Runtime Environment, 1.6.0_04-b12 OS: Linux, 2.6.24-17-generic, amd64 User Comments: Created attachment 61216 [details]
stacktrace
Build: NetBeans IDE 6.1 (Build 200804211638) VM: Java HotSpot(TM) 64-Bit Server VM, 10.0-b19, Java(TM) SE Runtime Environment, 1.6.0_04-b12 OS: Linux, 2.6.24-17-generic, amd64 User Comments: Created attachment 61220 [details]
stacktrace
Created attachment 61891 [details]
stacktrace
*** Issue 136888 has been marked as a duplicate of this issue. *** Created attachment 63507 [details]
stacktrace
*** Issue 127583 has been marked as a duplicate of this issue. *** I have found in issue 127583 there is a problem with lower/upper case in class names. In this case ElementHandle.resolve cannot resolve class pkg.BandLimiting from file pkg/Bandlimiting.java. *** Issue 140013 has been marked as a duplicate of this issue. *** Issue 140013 shows another class/file name inconsistency causing NPE: Cannot resolve ElementHandle[kind=OTHER; sigs=org.netbeans.tests.examples.packb.BeanD ]; file: /home/tester/Desktop/default/src/org/netbeans/tests/examples/packb/BeansD.java I've fixed the last case (BeansD) in the revision: http://hg.netbeans.org/main/rev/b6f5629b3134 Not sure about the others which I am not able to reproduce. If anyone can reproduce it in NB 6.5 newer than 07/22/08 please reopen this issue. *** Issue 143059 has been marked as a duplicate of this issue. *** *** Issue 146727 has been marked as a duplicate of this issue. *** Reopening - reproduced in NetBeans IDE 6.5 Beta (Build 200808111757) http://statistics.netbeans.org/exceptions/detail.do?id=127796 paulby: please attach your ${nb.userdir}/var/log/messages.log to this issue. It will help us to identify the problem.
Created attachment 71780 [details]
Message log
*** Issue 152135 has been marked as a duplicate of this issue. *** I just got a NullPointerException when trying to refactor->rename a method in one of my base classes. NB 6.5 offered to report the problem for me and I took it up on that offer...it then told me that my bug report was a duplicate of an existing one (presumably this one, but I don't see mine as a duplicate at the bottom of this list) nor do I see any attachments from my messages.log....but somehow I was added on the 'cc' list for this bug. Why is this languishing as a P3? Aren't NullPointerException at least a P2? Since I can't do this important refactor, I'm raising this to P2. By the way, currently this NullPointerException is reproducible every time on my machine. Is there something I can do to expedite the fixing of this bug? Steps to reproduce would certainly help a lot - it will likely be necessary to place a few breakpoints and do some debugging to find the cause. Thanks. BTW: the exception you reported is here: http://statistics.netbeans.org/analytics/exception.do?id=145618 At the moment, I can reproduce every time in my project. I'd be glad to help, but I can't send you the project. Tell me what to do - I imagine NB captured my messages.log when I submitted from within NB? I think on another bug a developer asked me to set some flags in NB to get extended debugging info - I don't remember what it is, but do you want me to turn that on? I was going to try and remove $HOME/.netbeans this morning to see if this fixes things, because I _really_ need to do this refactor this morning. I will save the old .netbeans/ directory, so if a corruption in it caused the problem, I'll hopefully be able to reproduce after I do this. The problem disappeared (i.e. I was able to do the refactor) once I removed $HOME/.netbeans and restarted the IDE. As I mentioned in the earlier comment, I kept the old .netbeans/ so I can still reproduce the problem if someone wants me to. I do consider it a problem - since I never manually mess around with $HOME/.netbeans. Therefore, NB itself is causing this problem. Let me know if I can do anything else. *** Issue 154221 has been marked as a duplicate of this issue. *** Fine, if you still have your old $HOME/.netbeans directory, please, look into your messages.log file and find the NPE. Just before it, there should be a message: Cannot resolve ElementHandle[...]. There should be a type name written in the message. Please, go into your old $HOME/.netbeans/var/cache/index and try to find the class/sig file that corresponds to the unresolved type name. If such file exists, attach it to this issue. Thanks. Hi dbalek, The "Cannot resolve:" shows sigs=com.netforensics.ui.admin.notification.AlarmNotificationDetailsPanel$SelectNotificationDestinationPanel$SelectDestinationAction$AlarmNotificationDetailsPanel It can't find that class - not surprising, since I don't think there should be such a class. I looked at the source code for com.netforensics.ui.admin.notification.AlarmNotificationDetailsPanel and note that the inner classes are only nested two deep - i.e. there's a SelectNotificationDestinationPanel and inside it, there's a SelectDestinationAction class. According to the sig above, there should be yet another class of the same name as the global class nested inside of SelectDestinationAction. If you want, I can attach the class file corresponding to SelectDestinationAction. The problem seems to be in the usages index. Could you please attach the index data files to this issue? (please go to your old $HOME/.netbeans/var/cache/index and find which segment directory (s1....s?) contains com.netforensics.ui.admin.notification.AlarmNotificationDetailsPanel. Then go into this directory and attach content of its 'refs' subdirectory). Thanks. Created attachment 75034 [details]
ignore - just testing attachments (previous attempt for tar failed)
DBalek, I don't know what the issue is, but I can't seem to upload binary files - not sure if the problem is on my side or netbeans (text files upload fine). Is there any way for you to check if NB site is causing the issue? thnx, tom Created attachment 75073 [details]
Test upload binary files
It seems to work fine for me - however - I think there is a size limit (1MB or so) for the attached files. Maybe you can try to zip it and send it directly to me. I sent the file directly to you as I'm still having trouble uploading the file. Thanks for sending the index files. Information about com.netforensics.ui.admin.notification.AlarmNotificationDetailsPanel$SelectNotificationDestinationPanel$SelectDestinationAction$AlarmNotificationDetailsPanel is really stored in the index. CCing tzezula - do you have any idea how the information could get there? *** Issue 152812 has been marked as a duplicate of this issue. *** *** Issue 156582 has been marked as a duplicate of this issue. *** Build: NetBeans IDE 6.5 (Build 200811100001)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-b33
OS: Windows XP, 5.1, x86
User Comments:
renaming a method
Stacktrace:
java.lang.NullPointerException
at org.netbeans.modules.refactoring.java.RetoucheUtils.getOverridingMethods(RetoucheUtils.java:219)
at org.netbeans.modules.refactoring.java.plugins.RenameRefactoringPlugin$2.run(RenameRefactoringPlugin.java:414)
at org.netbeans.modules.refactoring.java.plugins.RenameRefactoringPlugin$2.run(RenameRefactoringPlugin.java:387)
at org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:680)
at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:607)
at org.netbeans.modules.refactoring.java.plugins.RenameRefactoringPlugin.getRelevantFiles(RenameRefactoringPlugin.java:381)
Created attachment 75719 [details]
stacktrace
*** Issue 157431 has been marked as a duplicate of this issue. *** Overtake. Can't replicate. There was also big change in parsing and indexing infrastructure. So, it works for me. If there is again occurrence of this issue please reopen it. I just reproduced this on a brand new build of main-silver (as of an hour ago). I was trying to rename an abstract, overridden method. The overrides are in innerclasses in the current class. One possible explanation for why this happens is that when I do "Open Type", I see another occurrence of my class which is not correct; the reference is to a package where the class previously lived. (I've moved the class, using the Move refactoring in NetBeans). The old class name is still there. As tor wrote, it is still reproducible with rename refactoring. I have another duplicate (issue 135486). From log files it fails with 'Cannot resolve: ElementHandle[kind=CLASS; sigs=com.acquamedia.view.modules.types.subTypes.generalLink ]'. See http://statistics.netbeans.org/exceptions/messageslog?id=178313, http://statistics.netbeans.org/exceptions/messageslog?id=183987 or http://statistics.netbeans.org/exceptions/messageslog?id=185008. Unfortunately it is not possible to identify what is wrong from the log now. It will need more detailed debug info. *** Issue 135486 has been marked as a duplicate of this issue. *** Just got the same exception in 6.5 on Win Vista. Attaching log... Created attachment 80789 [details]
var/log/messages.log
Please add to netbeans.conf followining settings to improve loggin. Thank you. -J-Dorg.netbeans.api.java.source.ElementHandle.level=FINE -J-Dorg.netbeans.modules.java.source.usages.ClassFileUtil.level=FINE I understand the issue priority, but we have no successful scenario for reproducing. Lowering priority. *** Issue 164370 has been marked as a duplicate of this issue. *** how does reproducibility effect priority ? you know that the error is still happening, that it's a significant impact to the usefulness of the app. the fact that you don't have the tools to reproduce it yourself shouldn't effect priority Honza (jpokorsky) has a reproducable case of this problem. The thing is that the refactoring is using the staled Source (JavaSource). There are two possible solutions: 1) Refactoring will invalidate all sources before it's started. It's rather workaround than solution as the same problem may be in other features as it's quite generic problem. 2) The java module will invalidate needed parsers when the java file is updated. *** Issue 167850 has been marked as a duplicate of this issue. *** *** Issue 165970 has been marked as a duplicate of this issue. *** The Honza's case fixed in jet-main 357f6d4e7154 Integrated into 'main-golden', will be available in build *200910140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/357f6d4e7154 User: Tomas Zezula <tzezula@netbeans.org> Log: #120577:NullPointerException at org.netbeans.modules.refactoring.java.RetoucheUtils.getOverridingMethods *** Bug 184593 has been marked as a duplicate of this bug. *** *** Bug 178813 has been marked as a duplicate of this bug. *** *** Bug 192871 has been marked as a duplicate of this bug. *** still reproducible in 7 beta. See Bug 192871 *** Bug 195072 has been marked as a duplicate of this bug. *** *** Bug 176014 has been marked as a duplicate of this bug. *** Created attachment 106168 [details]
stacktrace
invoked Change method parameters on a class constructor
20 duplicates, 319 ERs ... more then P3 (also couple reports for 7.0 Beta 2) In fact it's not single issue. The NPE is just a cause of non resolve handle. Strictly speaking they are not duplicates of the fixed problem in comment #33 which had reproduceable case from Honza Pokorsky. To find other root cases I need a reproduceable case. Is anybody able to attach a reproduceable test case? If someone has a reproduceable case please attach it or send it. Otherwise I am closing this issue as incomplete. I've found 2 possible cases. Fixed jet-main c5b9690980f6 FIxed jet-main f9908b4fb46a But probably not all of them. If someone has another please attach the reproduceable case. Mariane, can QA verify the fix before I integrate it into 7.0? Thanks (In reply to comment #87) > Mariane, can QA verify the fix before I integrate it into 7.0? We will look at it today. Dik Jardo, it's important to test if the java index is not broken. (GoTo Type works). The case which caused the NPE was: 1) Create some abstract class Base with abstract method foo 2) Create some other class Holder 3) In the Holder class create an inner class Impl which extends Base 4) In the editor (not by refactoring) rename Holder to Holder2 (editor will complain that it has to be placed in the Holder2 file, rename it back to Holder. 5) Rename Base.foo method to Base.foo2 I have verified the fix in the following jet-main build and I agree with integration to 7.0: Product Version: NetBeans IDE Dev (Build jet-main-3754-on-110318) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) Integrated into 'main-golden', will be available in build *201103190400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c5b9690980f6 User: Tomas Zezula <tzezula@netbeans.org> Log: #120577:NullPointerException at org.netbeans.modules.refactoring.java.RetoucheUtils.getOverridingMethods The patches seem fine to me. Transplanted to release70: http://hg.netbeans.org/releases/rev/003e5042ef4f http://hg.netbeans.org/releases/rev/22aa8a48a501 Verified in the following build: Product Version: NetBeans IDE 7.0 RC1 (Build 201103230000) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) |