Data Field crashing in native code on startup.

When I build the app using "build for device", it does not crash. When I download it from Connect IQ App Store, it often crashes on startup. The logs in CIQ_LOG.txt are not very useful. They indicate that some invalid value was used. Likely a null value. The problem is that it is not in my code. I know this because I have added logging and try/catch blocks to all the classes in the initializer methods. If any of them had an exception, it would log that information with the name of the class but all I get is this (which also implies it is not in my code when it says "native function": UnexpectedTypeException: Expected Number/Float/Long/Double, given null/Number
native function
ERROR: Invalid Value
DETAILS: Failed invoking <symbol>
STORE_ID: ae433c7ad7064f808e29f64e3fc4add4
CALLSTACK:
@PC = 0x100002af
@PC = 0x100019d8

This happens on both my 1000 and 1030 but not all the time and only when it is downloaded from Garmin Connect IQ. Both devices are up to the latest firmware.

The code can be seen here: https://github.com/creacominc/connectiq-PowerField

Has anyone else seen this issue?
Does anyone have a suggestion about how to fix this issue?

Former Member over 8 years ago

Given that it might be an issue with a null value slipping through, and that the behavior differs as you describe, I might think it could possibly be a result of a not-yet-set object store value getting through. Obviously you have try/catch everywhere, but I would try adding in null checks after every app.getProperty() anyway.
I might also try deleting the object store and potentially the settings for your sideloaded versions, if you aren't already, just to recreate the environment a fresh store app would see.

If it is the case that your try/catch blocks are not catching the null exception, might want to create a thread in the bug report forum.

Former Member over 8 years ago

Not all Connect IQ errors are thrown as exceptions. Some failures directly result in a VM crash. The backtrace in your error log does point to application code, which you can look up in your applications debug.xml after building for the device in question. The PC values in the debug.xml file are in decimal as opposed to hex, so you will want to look up the converted values (268436143, 268442072). These values will indicate the failure occurred on the line number listed with the largest PC value less than these logged values.

riedid74 over 8 years ago

For all tests.

i think it bad in some case because info will be null in some case so if you test info.currentHeartRate the application crashes

if((info has :currentHeartRate) && (info.currentHeartRate != null))
{
m_hearts[e_CUR] = info.currentHeartRate;
}
else
{
m_hearts[e_CUR] = 0;

==================================
Replace by

if (info != null) {
if( info has :currentHeartRate) {

if(info.currentHeartRate != null)
{
m_hearts[e_CUR] = info.currentHeartRate;
}
else { m_hearts[e_CUR] = 0; }

}

else { System.println("Info don't have currenHeartRate"); }
}
else { System.println("Info is null"); }

lcj2 over 8 years ago

I would take a look at the API documentation, I believe there are a large number of ":has" checks that you repeat over and over against items that have been in the SDK since 1.0.0 and can be checked for null and don't need an existence check. This isn't a cause of the problem you have described but might save some processing time and complexity in expressions. So in the example above currentHeartRate has been included since 1.0.0 and there isn't a device which wouldn't have support for it (https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Activity/Info.html#currentHeartRate-instance_method).