NPE in ProjectionViewer.resetVisibleRegion

[ptziegler]

Let's make sure issue is not already fixed in latest builds first.

• I verified I can reproduce this issue against latest Integration Build of Eclipse SDK

Steps to reproduce

From a fresh installation and clean workspace:

• Compare some local changes using the Synchronize perspective
• Do some changes to the local file in the Compare view
• Save

Here is some relevant log output

From <workspace>/.metadata/.log

java.lang.NullPointerException: Cannot invoke "org.eclipse.jface.text.source.projection.ProjectionAnnotationModel.getAnnotationIterator()" because "this.fProjectionAnnotationModel" is null
	at org.eclipse.jface.text.source.projection.ProjectionViewer.resetVisibleRegion(ProjectionViewer.java:890)
	at org.eclipse.compare.contentmergeviewer.TextMergeViewer$ContributorInfo.updateViewerDocumentRange(TextMergeViewer.java:809)
	at org.eclipse.compare.contentmergeviewer.TextMergeViewer$ContributorInfo.internalSetDocument(TextMergeViewer.java:790)
	at org.eclipse.compare.contentmergeviewer.TextMergeViewer$ContributorInfo.setDocument(TextMergeViewer.java:699)
	at org.eclipse.compare.contentmergeviewer.TextMergeViewer.updateContent(TextMergeViewer.java:3134)
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.internalRefresh(ContentMergeViewer.java:818)
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.refresh(ContentMergeViewer.java:792)
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.handleCompareInputChange(ContentMergeViewer.java:1428)
	at org.eclipse.compare.contentmergeviewer.TextMergeViewer.handleCompareInputChange(TextMergeViewer.java:5608)
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.lambda$1(ContentMergeViewer.java:401)
	at org.eclipse.team.ui.synchronize.SaveableCompareEditorInput$1.run(SaveableCompareEditorInput.java:394)

Tested under this environment:

• Eclipse IDE/Platform version (as shown in Help > About): 2025-12 M2

Community

• I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

[ptziegler]

Probably due to ce17c9e

[iloveeclipse]

@danthe1st : I see many cases where fProjectionAnnotationModel is unconditionally dereferenced in ProjectionViewer. Could you please take a look?

[iloveeclipse]

#3460 is a fix limited to the currect NPE only.

[danthe1st]

I see many cases where fProjectionAnnotationModel is unconditionally dereferenced in ProjectionViewer. Could you please take a look?

I went through the "Members accessing" that field and from what I can see, all references to it are guarded by either a null check or a check for isProjectionMode() (sometimes in a caller).
The exceptions are:

• catchupWithProjectionAnnotationModel: This method should be called only by projection logic but could be called via subclasses
• handleVisibleDocumentChanged: Could be called by subclasses or in case there is a "visible document" that does not originate from folding
  resetVisibleRegion: The one this issue is about

[iloveeclipse]

The exceptions are:

Thanks. Feel free to amend this PR #3460 or create new one, as you like.

[danthe1st]

TL;DR: Your PR should be sufficient // technically catchupWithProjectionAnnotationModel is possible if there is some sort of "corrupted" state already (new ProjectionDocument(null), it would be possible to use something like Objects.requireNonNull or some sort of warning to detect this early.).

I overlooked the isProjectionMode() check in handleVisibleDocumentChanged leaving catchupWithProjectionAnnotationModel which doesn't make sense to be called when projections are disabled.

Note that isProjectionMode() doesn't check for fProjectionAnnotationModel but it requires fVisualAnnotationModel to be set which only happens in setDocument right after fProjectionAnnotationModel is set so that's safe.

For catchupWithProjectionAnnotationModel: This method bails out with a isVisibleMasterDocumentSameAsDocument check which requires the document to be set to the visible document's master document and if that is null, there would be a lot of other NPEs in other places.

One thing I didn't mention is reinitializeProjection (which is public but only called by catchupWithProjectionAnnotationModel) which requires the document to be set (so it's safe as with IsProjectionMode() calls though more indirectly).