Community
Participate
Working Groups
A Java NullPointerException is being thrown when useModule is called on an IPC module when the package path is incomplete. This error was encountered in ROV. ROV now attempts to initialize even if the package path is not complete. It calls useModule on all of the modules in the configuration, and catches exceptions from the ones that fail. The below exception, however, cannot be caught in JavaScript. In this use case, the IPC product is on the package path, but BIOS is not. Many of the IPC modules depend on BIOS modules, so it makes sense that some would fail to load. XDC should fail more gracefully than this, though, and does in most cases. Loading ti.sdo.utils.List WARNING: xdc.loadPackage('ti.sdo.utils'): package cycle: ti.sdo.utils,ti.sdo.io. converters,ti.sdo.io Loading xdc.runtime.knl.SyncNull Loading ti.sdo.io.DriverTypes js: java.lang.NullPointerException java.lang.NullPointerException at xdc.services.intern.xsr.Value$Obj.chkFld(Value.java:1164) at xdc.services.intern.xsr.Value$Obj.put(Value.java:1438) at org.mozilla.javascript.ScriptableObject.putProperty(ScriptableObject. java:1656) at org.mozilla.javascript.ScriptRuntime.setObjectProp(ScriptRuntime.java :1477) at org.mozilla.javascript.ScriptRuntime.setObjectProp(ScriptRuntime.java :1467) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:297 4) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.j ava:162) at xdc.services.intern.xsr.Invoke.call(Invoke.java:127) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:323 7) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.j ava:162) at xdc.services.intern.xsr.Invoke.call(Invoke.java:127) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:323 7) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.j ava:162) at xdc.services.intern.xsr.Invoke.call(Invoke.java:127) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:323 7) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.j ava:162) at xdc.services.intern.xsr.Invoke.call(Invoke.java:89) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:323 7) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.j ava:162) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:3 93) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:283 4) at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.j ava:173) at org.mozilla.javascript.Context.evaluateReader(Context.java:1227) at config.Shell.evaluateReader(Shell.java:825) at config.Shell.processReader(Shell.java:491) at config.Shell.processFile(Shell.java:553) at config.Shell.exec(Shell.java:765) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at xdc.tools.Server$1.run(Server.java:333) at java.lang.Thread.run(Unknown Source)
Try to fix in 3.20.04 Need to develop command line test to cover this issue
The bug is caused by an inconsistency in the object model when an exception is thrown in the middle of loading a package. A module in a package is not completely initialized, and when its field '$used' is accessed, Value.java throws a NullPointerException because there is no such field. Value.java does the right thing, it checks if 'proto' for an object has '$used' and when that's the case, Value.java tries to access that field. We shouldn't make Value.java check for '$used' in the object itself because incomplete objects should be detected somewhere else. In this particular case, an incomplete object is being considered complete because xdc.om.$curpkg points to a package whose load failed earlier, and when that same package is being loaded again, we just return it. Normally, a package can load itself only after it is completely initialized, so we keep accessing its fields as if it loaded completely. The question is what should xdc.om.$curpkg be set to when we throw an exception. A package pkgA could load pkgB, which then loads pkgC, which cannot be found. If we set xdc.om.$curpkg to a saved value 'pkgB', and then pkgA catches the exception, xdc.om.$curpkg is invalid. A solution where we set xdc.om.$curpkg to 'undefined' works for the test case in this bug report, and for now I think I'll stick to that solution.
- fixed in xdc-v49, as described in Comment 2.
Verified in CCSv4.2 xdctools 3.20.04.67.eng. I set up the package path to include IPC but omit BIOS, which uncovered the original issue. This time, ROV launched successfully without any Java exceptions.
Shipped in XDCtools 3.20.04
