ERA - Unhandled Exception?

It would be very helpful to debugging if the nature of the "Unhandled exception" was also provided in the error report in ERA:

Error Name: Unhandled Exception
Occurrences: 1
First Occurrence: 2020-06-25
Last Occurrence: 2020-06-25
Devices:
    fēnix® 5X / tactix® Charlie: 19.10
App Versions: Beta 3.8.7
Languages: eng
Backtrace:
    Engine.recalcTWDfromPosFlag:1218
    Engine.checkForATackOrJibe:1284
    Engine.doRacingStuff:642
    Engine.dispData:593
    Engine.GPSData:1678

is useful to locate the issue in the code, but just what is triggering the error on line 1218?

TWD = normalizeHeading(grooveCOG  -180 + jibeAngle/2);

Yes, it's a (very) intermittent error and no, I can't repro in the lab.

0 Travis.ConnectIQ over 5 years ago

Unfortunately we can't display the string returned by ex.getErrorMessage() because it is possible for a developer to pack user identifiable information into it and then our crash reporting system would smuggle that information off device (a GDPR violation).

If you, or the user, has created an APPS/LOGS/<APPNAME>.txt file on the device, the exception string does get written to that log file.

0 Travis.ConnectIQ over 5 years ago

If the error is indeed from that line of code, you have just a handful of things going on. The disassembly for that line looks something like this:

# TWD = normalizeHeading(grooveCOG - 180 + jibeAngle / 2);
lgetv 0
spush TWD
lgetv 0
spush normalizeHeading
getv
frpush
lgetv 1
ipush 180
subv
lgetv 2
ipush 2
divv
addv
invokem 2

You can check this yourself by compiling with -g and searching for the call to normalizeHeading in the generated output.

The instructions that are likely to be giving you problems are subv, divv, and addv.. the ones used to calculate the value to pass to normalizeHeading. All three of these instructions will throw an unexpected type exception if either argument is not a numeric type (Number Float, Long, Double). Most of the time we see this kind of error when the value is null.

0 Alan.raceQs over 5 years ago in reply to Travis.ConnectIQ

Travis.ConnectIQ said:
d smuggle that information off device (a GDPR violation).

I would love to understand how reporting the extra line like "UnexpectedTypeException: Expected Number/Float/Boolean/Long/Double, given null" that we get in CIQ_LOG.YAML would risk violating GDPR.

0 9635560 over 5 years ago in reply to Alan.raceQs

Developers can throw their own exceptions and it doesn’t take a genius to work out how to make an exception message that contains sensitive info. Log files have been used in lots of high profile scams.

0 Nikeow over 5 years ago in reply to 9635560

I guess it's a when there's a will, there's a way kind of thing.

0 9635560 over 5 years ago in reply to Nikeow

It’s also a useful debug technique- it doesn’t have to be malicious.

0 Alan.raceQs over 5 years ago in reply to 9635560

But surely the error description ("UnexpectedTypeException: Expected Number/Float/Boolean/Long/Double, given null") is generated by CIQ. How could the humble developer "pack user identifiable data" into that?

0 9635560 over 5 years ago in reply to Alan.raceQs

Well _that_ exception is defined by Garmin, but it’s easy to extend Exception and set your own message for your own error.

I did it a lot with difficult bugs in other languages where neither breakpoint nor console logs would work to find out info immediately prior to the bug manifesting.

0 Alan.raceQs over 5 years ago in reply to 9635560

Yes, but we’re talking Monkey C, and I challenge you to “extend exception” here!

0 Travis.ConnectIQ over 5 years ago in reply to Alan.raceQs

If we did as you proposed and displayed error strings for built-in exception types only, users could still smuggle data out of the system with something like this:

throw UnexpectedTypeException(privateDataString, 0, 0);

We could possibly add a flag to indicate where the message came from (was it from user code or from inside the vm), and then log it if it came from within the vm... but there are ways this could be hijacked as well.