[Soot-list] Eclipse problem

[Eric Bodden]

I briefly looked into this.

This appears to be a bug in Eclipse or some other plugin you are
using. Line 59 of SootDeltaVisitor looks as follows:

SootPlugin.getDefault().getManager().addToLists(delta.getResource());

According to the Eclipse API, delta.getResource() should not return
null, however, apparently it does return null in your case.

Eric

--
Dr. Eric Bodden
Software Technology Group, Technische Universität Darmstadt, Germany
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt



On 19 August 2010 18:03, Hal Hildebrand <hal.hildebrand at gmail.com> wrote:
> Hmm.  I guess I spoke too soon.  Obviously, some interactions here that are a bit hard to pin down.  But the null pointer exception appeared again.  Stack trace below.  Note that now the editors are acting up again as well, losing unsaved changes when switching between files.
>
> java.lang.NullPointerException
>        at ca.mcgill.sable.soot.resources.SootResourceManager.addToLists(SootResourceManager.java:125)
>        at ca.mcgill.sable.soot.resources.SootDeltaVisitor.visit(SootDeltaVisitor.java:59)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
>        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48)
>        at ca.mcgill.sable.soot.resources.SootResourceManager.resourceChanged(SootResourceManager.java:144)
>        at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291)
>        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
>        at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
>        at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
>        at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:327)
>        at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1181)
>        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1984)
>        at org.tigris.subversion.subclipse.core.util.JobUtility$1.run(JobUtility.java:20)
>        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>
> On Aug 19, 2010, at 8:24 AM, Hal Hildebrand wrote:
>
>> Well, I reinstalled the Soot plugin and the problem seems to have vanished.  Don't know what's up with that, whether it was some bad interaction with a plugin version I had installed or what.  But that's gone.  Sorry for the noise - should have rechecked before posting.
>>
>> On Aug 18, 2010, at 11:46 PM, Eric Bodden wrote:
>>
>>> Hi Hal.
>>>
>>>> In the Helios Release, there is a null pointer exception that occurs when
>>>> the hover is activated.  I haven't had time to track it down, unfortunately.
>>>> But when the Soot plugin is installed, basically you get very odd behavior
>>>> (and incredibly frustrating behavior) in that editors that don't have
>>>> unsaved changes will lose these changes when switching to a new file and
>>>> then back again.  It's definitely Soot's problem as I've verified that
>>>> things are fixed when the plugin is removed.
>>>
>>> Can you please let us know how to reproduce this? I am using Helios
>>> too, and I have not noticed such behavior.
>>>
>>> Eric
>>
>
>