Help debugging released version


I'm getting a crash report with the following CIQ_LOG.txt:
ERROR: Unexpected Type Error
DETAILS: Failed invoking <symbol>
STORE_ID: d76bf3e20924470eb86b62f372ecc0ae
CALLSTACK:
@PC = 0x1000f1bf

ERROR: Unexpected Type Error
DETAILS: Failed invoking <symbol>
STORE_ID: d76bf3e20924470eb86b62f372ecc0ae
CALLSTACK:
@PC = 0x1000f1bf

ERROR: Unexpected Type Error
DETAILS: Failed invoking <symbol>
STORE_ID: d76bf3e20924470eb86b62f372ecc0ae
CALLSTACK:
@PC = 0x1000f1bf

ERROR: Unexpected Type Error
DETAILS: Failed invoking <symbol>
STORE_ID: d76bf3e20924470eb86b62f372ecc0ae
CALLSTACK:
@PC = 0x1000f1bf

ERROR: Unhandled Exception
DETAILS: NONE
STORE_ID: d76bf3e20924470eb86b62f372ecc0ae
CALLSTACK:
UnexpectedTypeException: Expected Number/Float/Long/Double, given null/Number


The callstack reference decodes to to Dec 268497343 and the closest I can get to that is 68497329 or 268497347,

this gets me to lines 341, 344


341: view.dispMarksMenu();
342:
343: }
344: return true;

So the reported stacktrace isn't a code line.
The user restarted after a couple of days and the app runs fine. How do I deal with that?

Oh yes, I wonder who thought it would be a good idea to report the address as Hex in the error log and decimal in the debug,xml?
  • Former Member
    Former Member
    The address returned on a release stack trace isn't always going to exactly match an address that is present in the debug.xml. This is because each Monkey C instruction will compile into multiple bytecodes. In the debug.xml you are looking for the first address less than the address reported in the error long. In this case your crash indicates that the code generated from line 341 was executing when the crash occurred.

    There doesn't appear to be anything obvious that could cause an unexpected type error in that line of code. We might assume that something prevented a second level of the backtrace from being generated, which could mean that the unexpected null occurred somewhere inside the call to dispMarksMenu().