Weird crash passing constant at specific position (order) in module with SDK 2.4 beta

Weird crash when referencing a constant a specific order position in a module with SDK 2.4 beta on device (and simulator).

The Environment:
- MacOS 10.13
- Eclipse Oxygen.1a Release (4.7.1a)

Detailed description:

My "UTC Titanium" watch face functions properly with the current CIQ implementations (CIQ 1.4.x and CIQ 2.3.x) however users running beta versions with CIQ 2.4 were reporting that the watch face crashes. I can confirm that the crash also happens on the simulator running the SDK 2.4 beta. This is without any code changes whatsoever.

The simulator reports the crash happens when calling the drawCircle but only when passing it a specific constant from a module in another file, which contains all the constants. If I move this constant further down in the module then the crash happens somewhere else, at the first use of the constant now in the position of the original constant. The position happens to be the 17th constant in my file and this only appears to be an issue when calling draw methods on a Dc object from a BufferedBitmap. Calls to draw methods on devices running CIQ 1.4 or calling System.println with that constant work as expected, passing in the numerical value.

My constant module looks something like this...

module DeviceOverride {
const SOME_VALUE_00 = 1;
const SOME_VALUE_01 = 1;
const SOME_VALUE_02 = 1;
const SOME_VALUE_03 = 1;
...
const SOME_VALUE_16 = 1;
const SOME_VALUE_17 = 1; // passing this constant to a method seems to send a Class reference
const SOME_VALUE_18 = 1;
}


Passing the 16th and 18th values to a method is fine but passing the 17th constant causes the following error, as displayed in the console...

(null)
Unhandled Exception
UnexpectedTypeException: Expected Number/Float/Boolean/Long/Double, given Class definition
native function
native function
onUpdate in /Users/douglasr/develop/garmin/watchfaces/UTCTitanium/source/UTCTitaniumView.mc:199


The quick fix is simply to add a bogus, unused constant in the 17th position and everything seems to work again. I added a bunch of other bogus constants to see if it occurs in any kind of pattern but it only seems to crash when accessing the 17th constant, which in my case is a number but is being passed as a Class.


Steps to reproduce:

1. Load project "UTCTitaniumCrash" in Eclipse (NOTE: project has been emailed to Connect IQ team only)
2. Run project.
3. See simulator crash.
4. To see simulator run fine, uncomment the BOGUS constant on line 40 of Fenix5.mc source file.
5. Scratch your head as to what is going on.


Additional information:

None.


Code sample:

Emailed a stripped down version to Connect IQ team.
  • Former Member
    Former Member
    That is weird. Just out of potentially misguided curiosity, what is the result if you try to print out the value of the 17th constant that causes the issue? Does it yield a class definition?
  • That is weird. Just out of potentially misguided curiosity, what is the result if you try to print out the value of the 17th constant that causes the issue? Does it yield a class definition?


    Nope, using that constant in method calls other than the Dc of a BufferedBitmap are fine.

    I just added in a note about that to my original post; you will see about a million edits because I keep having to add bit by bit of my original message, editing as I go to avoid the dreaded forum JSON error when saving.
  • Just wanted to post an update. And no, not to increase my post count, since that would be against the forum rules. :P

    I added the bogus constant in the 17th position and exported the app using SDK 2.3.4, which I then uploaded to the store. The f?nix 5X user who first reported the issue got back to me that this workaround seems to fix the issue on the device also (beta FW with CIQ 2.4). So my five hours of debugging (read: frantic hacking) appear to have been worth it. :)

    But I'd still like to know what is happening to cause this when the cause is found. If you're allowed to disclose what it was.

    Cheers,
    Douglas
  • Former Member
    Former Member
    We've got the ticket working. Thanks for the updates. I'm glad you were able to find the workaround, but we are definitely taking a look!

    Thanks,
    -Coleman
  • Former Member
    Former Member
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
  • There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.


    If I could like this more than once I would have -- reading this was the best way to start my day.
  • That is about as good as this quote.

    There are 10 kind of people in this world, those that understand binary, and those that don't.
  • Former Member
    Former Member
    This has been fixed in version 2.4.1. Please let us know if there are any further issues.