Community
Participate
Working Groups
No idea what this is or where it came from. Was looking at some doc plugins and had one html editor open in the workbench. !SESSION 2007-06-07 11:14:48.921 ----------------------------------------------- eclipse.buildId=I20070606-0010 java.version=1.5.0_06 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 !ENTRY org.eclipse.core.jobs 4 2 2007-06-07 11:23:54.937 !MESSAGE An internal error occurred during: "Identifier Update Job". !STACK 0 java.lang.NullPointerException at org.eclipse.ui.internal.activities.Identifier.fireIdentifierChanged(Identifier.java:111) at org.eclipse.ui.internal.activities.MutableActivityManager.notifyIdentifiers(MutableActivityManager.java:240) at org.eclipse.ui.internal.activities.MutableActivityManager.access$3(MutableActivityManager.java:229) at org.eclipse.ui.internal.activities.MutableActivityManager$2.run(MutableActivityManager.java:781) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Looking closer at this code (ie: with my eyes open) I see that we do indeed do a null check for listeners. I dont see any way this can be happening unless modifying an ArrayList concurently (ie: removing a node) can result in a state where we somehow have a null element. I will approach this from a pooched-up-threading perspective.
I just got the same exception while starting up Eclipse on my existing workspace -- perhaps my information can help: Eclipse SDK 3.3.0 (I20070625-1500) on WinXP SP1, Sun 1.6.0_01 JVM EMF 2.3.0, CDT 4.0.0, DSDP-TM 2.0.0.1, Subclipse 1.1.9 installed Perspective on startup is PDE Perspective Active Views: Package Explorer, PDE Manifest Editor for a Fragment, Search Selection in the Package Explorer is the MANIFEST.MF file of my fragment.
This was probably caused by the fix for bug 93364.
I believe the fix is now in HEAD. The optimization mentioned previously causes certain identifier enablement to happen in a background job and Identifiers (much like most of our workbench apis) assume that they're being run on the UI thread. I've factored out the actual event firing to be once again on the right thread.
I've verified that the code is in I20080205-0010 but I can't think of a consistent way to reproduce this bug to verify the behaviour. The code is pretty foolproof, however, so I am inclined to mark this as verified.
I just got this too, using Eclipse 3.3. It happened while changing to the Team Synchronizing perspective, but I am unsure if it is related. What I would call a "spurious NPE". Very strange indeed. Glad to see it's fixed in 3.4, thanks.
