Debugging NPE during CanonicalizerPhase

[Andreas Woess]

Hi Stefan,

I'll make the FrameAccessNode more robust to fix this bug.
> Are you suggesting that the frame slots should be initialize with a language value?
No, in this case the problem is that the FrameSlot object passed to
frame.getObject was found to be null.

I've run the Loop.som program with your command line below and found the
cause:
You have this code in ContextualNode:
>   protected MaterializedFrame determineContext(MaterializedFrame frame) {
>     MaterializedFrame ctx = frame;
>     if (contextLevel > 0) {
>       int i = contextLevel;
>
>       while (i > 0) {
>         try {
>           FrameSlot blockSelfSlot =
> ctx.getFrameDescriptor().findFrameSlot("self");
>           Block block = (Block) ctx.getObject(blockSelfSlot);
>           ctx = block.getContext();
>           i--;
>         } catch (FrameSlotTypeException e) {
>           throw new RuntimeException("This should really really never
> happen...");
>         }
>       }
>     }
>     return ctx.materialize();
>   }

findFrameSlot will probably never return null here, but the compiler
cannot know this and creates one branch where the frameSlot is null and
one where it isn't -- in both branches it would call getObject. So a
simple workaround would be to explicitly check for a (non-)null result here.

In any case, you should avoid findFrameSlot in compiled code and try to
resolve frame slots at compile time, if possible. Or, at least
specialize the access node after resolving the frame slot. In all
likelihood, the frame slot will be the same every time.

- andreas

On 07.08.2013 08:41, Stefan Marr wrote:
> Hi Andreas:
>
> On 07 Aug 2013, at 00:58, Andreas Woess <andreas.woess at jku.at> wrote:
>
>> Looks like a frame slot field in one of your nodes was null at compile
>> time and read as a constant value. I'll have a look at your code tomorrow.
> That could well be.
> Are you suggesting that the frame slots should be initialize with a language value?
>
> During execution there shouldn't be any reads of uninitalized values, but with the compilation it might be.
>
> Thanks
> Stefan
>
>
>> We'll add better checks soon.
>>
>> - andreas
>>
>> On 07.08.2013 00:35, Stefan Marr wrote:
>>> Hi Thomas:
>>>
>>> On 06 Aug 2013, at 08:56, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
>>>
>>>> Can you upload the IGV graph that is produced by the -G:+DumpOnError flag? You should have "./mx.sh igv" running in parallel and then export the graph as an XML file. Also, what is your stack trace?
>>> Well, I would like to, but the NPE getting into the way…
>>>
>>> Here the two stack traces, once with and once without igv:
>>>
>>> http://soft.vub.ac.be/~smarr/downloads/truffle/error-with-igv.txt
>>> http://soft.vub.ac.be/~smarr/downloads/truffle/error-without-igv.txt
>>>
>>> That's the result with the very latest code from today.
>>> Invocation looks like this:
>>> ./mx.sh --vm server --debug build debug && ./mx.sh --debug --vm server vm -G:+DumpOnError -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Loop.som
>>>
>>> So far, I was only able to confirm that the null constant object really appears only in the CanonicalizerPhase.
>>> I added checks on the whole graph for everything that happens before the pass.
>>>
>>> One question Michael had, and that I investigate is whether there was anything related to TruffleSOM, and I think, the first null constant that was a problem was actually not directly related to my code. But I haven't had the chance to investigate further yet.
>>>
>>> Thanks
>>> Stefan
>>>
>>> PS: TruffleSOM can be build and tested like this:
>>>
>>>  $ git clone https://github.com/smarr/TruffleSOM.git som
>>>  $ cd som
>>>  $ ant test
>>>