Community
Participate
Working Groups
Created attachment 169850 [details] Guard against NPE I got a report from a user of an NPE. I don't know the details of his setup so I'm not sure how to reproduce it, but I figure we should guard against it. java.lang.NullPointerException at org.eclipse.cdt.dsf.mi.service.CSourceLookup.getSourceLookupPath(CSourceLookup.java:91) at org.eclipse.cdt.dsf.mi.service.CSourceLookup.getSourceLookupPath(CSourceLookup.java:102) at org.eclipse.cdt.dsf.mi.service.CSourceLookup.getSourceLookupPath(CSourceLookup.java:102) at org.eclipse.cdt.dsf.mi.service.CSourceLookup.setSourceLookupPath(CSourceLookup.java:71) at org.eclipse.cdt.dsf.gdb.launching.FinalLaunchSequence$13.execute(FinalLaunchSequence.java:324) at org.eclipse.cdt.dsf.concurrent.Sequence.executeStep(Sequence.java:443) at org.eclipse.cdt.dsf.concurrent.Sequence.access$2(Sequence.java:366) at org.eclipse.cdt.dsf.concurrent.Sequence$2.handleSuccess(Sequence.java:413) at org.eclipse.cdt.dsf.concurrent.RequestMonitor.handleCompleted(RequestMonitor.java:346) at org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:291) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
Pawel, can you review? I'll wait for your review to commit because we are so late in the release cycle.
All this could go away if we fixed Bug 225805. I'll target that one for 8.0
The guard should be accompanied by an assert until we know that there isn't a deeper issue at hand.
+1, use of IResource.getLocation() has changed when the resource system was refactored to support URIs.
(In reply to comment #4) > +1, use of IResource.getLocation() has changed when the resource system was > refactored to support URIs. Committed to HEAD. Thanks (In reply to comment #3) > The guard should be accompanied by an assert until we know that there isn't a > deeper issue at hand. John, now that there is somewhat of an explanation for this happening, do you still want the assert?
Fixed
(In reply to comment #5) > John, now that there is somewhat of an explanation for this happening, do you > still want the assert? I'm not really getting the explanation, but if you feel there is one, then there's no need for an assert.
(In reply to comment #4) > +1, use of IResource.getLocation() has changed when the resource system was > refactored to support URIs. Looking at the history of IResource.getLocation(), the javadoc refers to getLocationURI() all the way back to the 3.5 release. So, I'm also confused about if this NPE is expected or not? Pawel, do you have more details?
(In reply to comment #8) > So, I'm also confused about if this NPE is expected or not? Pawel, do you have > more details? IResource.getLocation() can return null if the resource doesn't actually exist or if it's a remote resource. If the resource doesn't exist, I think we can blissfully ignore the NPE, in case of non-local resources I'm not sure what the valid action should be... it's not a use case we've discussed :-)
*** cdt cvs genie on behalf of mkhouzam *** Bug 314303: Protect against NPE. [*] CSourceLookup.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/CSourceLookup.java?root=Tools_Project&r1=1.2&r2=1.3
