Bugfix for #2453: NPE in BarContentAssistProcessor.

[nettozahler]

Fixes #2453 .
This bugfix simply adds a check for NULL which was missing. In case of NULL a default value is returned.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

tests/org.eclipse.ui.genericeditor.tests/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From b9433e179e84806fe885206a3d11ea6bdf724c26 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Sun, 3 Nov 2024 21:58:54 +0000
Subject: [PATCH] Version bump(s) for 4.34 stream


diff --git a/tests/org.eclipse.ui.genericeditor.tests/META-INF/MANIFEST.MF b/tests/org.eclipse.ui.genericeditor.tests/META-INF/MANIFEST.MF
index f95c0ce33f..a3dd34a3a5 100644
--- a/tests/org.eclipse.ui.genericeditor.tests/META-INF/MANIFEST.MF
+++ b/tests/org.eclipse.ui.genericeditor.tests/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Plugin.name
 Bundle-SymbolicName: org.eclipse.ui.genericeditor.tests;singleton:=true
-Bundle-Version: 1.3.500.qualifier
+Bundle-Version: 1.3.600.qualifier
 Bundle-Vendor: %Plugin.providerName
 Bundle-Localization: plugin
 Export-Package: org.eclipse.ui.genericeditor.tests,
-- 
2.47.0

Further information are available in Common Build Issues - Missing version increments.

[github-actions]

Test Results

 1 821 files  ±0   1 821 suites  ±0   1h 48m 42s ⏱️ + 3m 8s
 7 724 tests ±0   7 496 ✅ ±0  228 💤 ±0  0 ❌ ±0 
24 333 runs  ±0  23 586 ✅ ±0  747 💤 ±0  0 ❌ ±0 

Results for commit 113a645. ± Comparison against base commit c1c681a.

[mickaelistria]

While null-check are always welcome, I'm more curious about in which context can this issue be happening? The document isn't supposed to be null at that stage, so maybe the issue is earlier in the execution chain?

[nettozahler]

Since the affected class belongs to test code and the NPE happens when locally running org.eclipse.ui.genericeditor.tests.CompletionTest I suggest not to spend more time for further investigations until this bug occurs in productive code. Deeper investigations would be out of my personal scope anyway.

[ravnskjaer]

To answer the question above about how the document can be null here: the editor is closed in the test teardown while computeCompletionProposals is still running on a background thread, so the viewer has already been disposed and viewer.getDocument() returns null.

This has been harder to hit since August 2025, when a null check was introduced in f70ee0a. A small window remains, because the document is fetched again after the check without a guard. So the NPE is suppressed in practice, but the underlying race is still there (if you consider it a problem in test code).

To reproduce

1. Temporarily remove the null check in BarContentAssistProcessor.computeCompletionProposals.
2. In LongRunningBarContentAssistProcessor.computeCompletionProposals, add this just above the call to super.computeCompletionProposals (after the existing try/catch):

   try {
       Thread.sleep(300); // temporary: let teardown close the editor first
   } catch (InterruptedException e) {
       // ignore
   }

3. Run CompletionTest (on macOS, remove @DisabledOnOs from testCompletionFreeze_bug521484 first).

Result: testCompletionFreeze_bug521484 passes and the NPE is logged.

Root cause

1. computeCompletionProposals is still running when the editor is closed in teardown.
2. It keeps going after being interrupted (it swallows the InterruptedException and carries on).
3. It then reads viewer.getDocument() without a null check.

The sleep makes the processor outlast the interrupt and the editor close (1 and 2); removing the null check supplies 3.

Suggested fix

Read the document once into a local variable, return no proposals if it is null, and use that variable throughout the method.

[nettozahler]

Thanks for the detailed problem analysis. IMHO my fix in this PR contains exactly what you have suggested. But currently this old fix-branch has conflicts that must be resolved before merging.

[ravnskjaer]

Yes, your change covers what I suggested. Would you like to rebase the branch to resolve the conflicts? If you’d rather not, I can open a new PR on current master with your change, crediting you as co-author.

[nettozahler]

I can do the rebase when I find some time. If you have some pressure and do not want to wait, you can also open a new PR as suggested.

[ravnskjaer]

Ok, thank you - please go ahead, no pressure from my side. Just wanted to follow up.

[nettozahler]

I rebased and force-pushed the PR. Now we need someone who is willing to merge it. Maybe @akurtakov ?