Crash dump "memory is not present"

Adam,

There is a known bug in 5.3 where CCS incorrectly decodes memory sections over 0xffe0 in size when using this format.  Since this file contains sections that are 0x19000 in size, this is why you are running into this.

You can work around this by reducing the max section size to 0xffe0.  The bug has already been fixed in CCS 5.4, but that's not yet in beta.  If reducing the sections is not an easy solution for you, I can work with you on obtaining an early version of CCS 5.4 that contains the fix.

Darian

Hi, Darian,

Thanks for the quick response. Limiting memory section size to 0xffe0 resolves the "memory is not present" error.

However, the analyzeStackMemory call now results in a Java exception (see below).

I've attached files to reproduce it. Again data is zeroed and register config removed from the dump, but the same error is produced with real data.

--Adam

6646.crashdump.2.zip

org.mozilla.javascript.WrappedException: Wrapped com.ti.xpcom.XPCOMException: The function "getResult" returned an error condition  (0x80040111) (AnalyzeCrashDump-TI.js#18)
        at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1693)
        at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:160)
        at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:204)
        at org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:86)
        at org.mozilla.javascript.gen.c1._c0(AnalyzeCrashDump-TI.js:18)
        at org.mozilla.javascript.gen.c1.call(AnalyzeCrashDump-TI.js)
        at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
        at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
        at org.mozilla.javascript.gen.c1.call(AnalyzeCrashDump-TI.js)
        at org.mozilla.javascript.gen.c1.exec(AnalyzeCrashDump-TI.js)
        at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:503)
        at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:425)
        at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:391)
        at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:382)
        at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:179)
        at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:100)
        at org.mozilla.javascript.Context.call(Context.java:528)
        at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:450)
        at org.mozilla.javascript.tools.shell.Main.exec(Main.java:162)
        at com.ti.ccstudio.apps.internal.scripting.RunScript$1.run(RunScript.java:88)
Caused by: com.ti.xpcom.XPCOMException: The function "getResult" returned an error condition  (0x80040111)
        at com.ti.xpcom.internal.XPCOMJavaProxy.callXPCOMMethod(Native Method)
        at com.ti.xpcom.internal.XPCOMJavaProxy.invoke(XPCOMJavaProxy.java:142)
        at $Proxy71.getResult(Unknown Source)
        at com.ti.debug.engine.events.data.impl.StackAnalysisEventData.getResult(StackAnalysisEventData.java:21)
        at com.ti.debug.engine.scripting.CallStack.analyzeStackMemory(CallStack.java:164)
        at com.ti.debug.engine.scripting.CallStack.analyzeStackMemory(CallStack.java:183)
        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 org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
        ... 18 more

Adam,

I'm not sure why the exception doesn't include the problem - I'm looking into that now.  However the issue is that debug symbols are used to unwind the stack and the script doesn't load any.  Additionally, if you've zeroed all the data, it also won't find any frames in the stack range specified and will also fail for that reason too.

Darian

Darian,

For the sake of posting on a public forum I am removing the data and not loading the ELF file, etc. Using my real crash dump with good data and loading symbols from a good ELF file (with DWARF debug included) I get the exact same Java exception.

--Adam

Adam,

Modify the analyze call to add a "true" at the end like this:

debugSession.callStack.analyzeStackMemory( 0x8e1fd000, 0, 0x8000, true );

That will cause debugging info to be printed to stdout.  If that doesn't make it obvious what's wrong, please post that to this thread. 

Darian

Darian,

Thanks, that worked. 0x7FF0 section size limit fixed the problem so now I am getting output from the stack walker.

Thanks!

--Adam