| Summary: | Null Pointer in JavaBreakpoint | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Aaron Luchko <aaron> |
| Component: | Debug | Assignee: | Sarika Sinha <sarika.sinha> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sarika.sinha |
| Version: | 3.0 | ||
| Target Milestone: | 4.6 M3 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Move to JDT/Debug This implies a class prepare event was delivered from the target VM with a "null" reference type. According to the JDI spec, this is not an expected condition. Steps to reproduce would be valuable. For now, marking as defered. Does not seem like a common occurrence. unable to reproduce As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. Looks like it is happening too often and we can check first the null type for typName and then the next check. https://dev.eclipse.org/recommenders/committers/confess//#/problems/54c4eea1bee810030da05d5c/details As mentioned in Bug 418473, Breakpoint typename can be null. Breaking the null checks in 2 different steps. Fixed via - http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=f43878344bb18c043b87d1614d02450e3c1e3f9a |
I was using RC3 and doing hyades development, hyades wasn't installed in my plugins but the hyades projects were open in my workspace. The workspace I was using was originally produced by the M9 build if that's any help. The null pointer occured during one of a long series of debugging sessions I had been running, the backtrace was $ java.lang.NullPointerException at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.installableReferenceType(JavaBreakpoint.java:318) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleClassPrepareEvent(JavaBreakpoint.java:276) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent(JavaBreakpoint.java:256) at org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:137) at org.eclipse.jdt.internal.debug.core.EventDispatcher.run(EventDispatcher.java:221) at java.lang.Thread.run(Thread.java:534) after the backtrace I cannot be sure but the debugging session seemed to stall, the runtime-workbench continued to refresh but actions would no longer have any effect. I tried terminating the runtime-workbench and debugging again a number of times but again the application would go unresponsive in certain areas, it occurs to me that the unresponsive areas may of been in the same spots as some disabled Breakpoints but I can't confirm that either way the exact spot the program grew unresponsive varied, the state of the debugging window didn't reflect having hit any kind of breakpoint. I shut down the program after noting the Null Pointer did show up once more later on (important to note that I debugged many times before and after with out the null pointer). The problem appears to have desisted when I restarted eclipse. I'm sorry I can't give steps to reproduce but felt I might as well give what I have, I'll continue to play around with it and update this report if I find any more info.