Bug 176269 - [index] NullPointerException filtering for exception breakpoint
Summary: [index] NullPointerException filtering for exception breakpoint
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M6   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 178459 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-03-03 00:18 EST by Darin Swanson CLA
Modified: 2007-03-20 19:41 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Swanson CLA 2007-03-03 00:18:19 EST
Eclipse 3.3 M5

I was attempting to set an exception breakpoint for ClassCastException
I typed in ClassCastExceptoin
While it was filtering I backspaced and re-typed

After the first occurrence I could not reproduce

java.lang.NullPointerException
at org.eclipse.jdt.internal.core.search.JavaSearchScope.normalize(JavaSearchScope.java:506)
at org.eclipse.jdt.internal.core.search.JavaSearchScope.encloses(JavaSearchScope.java:384)
at org.eclipse.jdt.internal.core.search.JavaSearchScope.indexOf(JavaSearchScope.java:369)
at org.eclipse.jdt.internal.core.search.JavaSearchScope.getAccessRuleSet(JavaSearchScope.java:476)
at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.getAccessRuleSet(JavaWorkspaceScope.java:73)
at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.acceptMatch(InternalSearchPattern.java:42)
at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.findIndexMatches(InternalSearchPattern.java:89)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:325)
at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:114)
at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:64)
at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:261)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:777)
at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:780)
at org.eclipse.jdt.internal.debug.ui.breakpoints.AddExceptionDialog.fillContentProvider(AddExceptionDialog.java:475)
at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.filterContent(FilteredItemsSelectionDialog.java:2055)
at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$AbstractFilterJob.internalRun(FilteredItemsSelectionDialog.java:1940)
at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$AbstractFilterJob.doRun(FilteredItemsSelectionDialog.java:1901)
at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$AbstractFilterJob.run(FilteredItemsSelectionDialog.java:1881)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Comment 1 Frederic Fusier CLA 2007-03-06 06:08:44 EST
Looking at the stack trace, this NPE can only happen if EntryResult.getDocumentNames(...) returns an array with null values (in InternalSearchPattern.findIndexMatches(...) line 87.

This may happen if DiskIndex.readDocumentName(...) returns a null value... Looking at the implementation, I do not understand how this would be possible!? I'll add some traces to get more information and have a chance to understand in which circumstances this can happen...

Note that this possibility is taken into account in AndPattern findIndexMatches method as "if (names[i])" condition exists before accepting the match... Not sure if we can just add the same protecion in InternalSearchPattern without clearly understand how this can happen...
Comment 2 Kent Johnson CLA 2007-03-06 13:36:29 EST
Its possible that DiskIndex.readDocumentName(...) could answer null if reading the chunk of names failed with an IOException, but the half empty chunks were still cached.

I suggest we null out the cachedChunks if a IOException is caught & rethrown.
Comment 3 Frederic Fusier CLA 2007-03-16 06:56:40 EDT
Fixed by Kent when he cleaned up stream reading...
Released for 3.3 M6 in HEAD stream (v_741).
Comment 4 Frederic Fusier CLA 2007-03-16 06:59:50 EDT
.
Comment 5 Frederic Fusier CLA 2007-03-20 12:24:04 EDT
Verified for 3.3 M6 while moving this bug to Kent...
Comment 6 Darin Swanson CLA 2007-03-20 19:41:56 EDT
*** Bug 178459 has been marked as a duplicate of this bug. ***