Device crash - running CIQ widget

I have not been able to reproduce the crash. I do think a device FW issue is a likely culprit unless there is some fluke in your widget that causes it to do something bad in a scenario I have been unable to trigger. Your widget maxed out at 202 memory allocations, which is well below the system limit. This could be an error in the main device firmware, or the VM may be leaking allocations somewhere.

I am planning on sending you a beta version of VivoActive firmware when the next one is available to me. If you can reproduce this crash on a beta firmware, it will generate a memory dump that I can use to trace the source of the issue.

Cool! I'm now out of the habit of running the widget right after I disconnect from USB or right after the fireworks, but I can be retrained!

BTW, with the 202 allocations, what is the system limit? If it's 500, I might have to worry about an app I'm building, but if it's 10000, I'll be safe for a long time!

The system limit depends on the device, but it can be as low as the ~500 range. Unless you are doing some specific things that I know I could blow the allocation limit out with, you should be safe. Objects in ConnectIQ are big enough, that you are almost certainly going to blow your 64KB budget before you run out of allocations. Things like ints/floats/booleans don't take up an allocation.

So, the VM does it's own memory management - it gets a big chunk from the device and then uses it as needed?

For example, if I create an array of 25x4, and for each of the "4", they are two floats and two small strings, that's not 100 allocations at the FW level, correct? More like 1 or 2?

Well, small strings are an exception, because strings require dynamic allocation.

This is probably (definitely) further down the rabbit hole than I should be going, but if you are really trying to do something that is going to use a ton of small strings and arrays...

Each array has a dynamic allocation. This creates some odd situations with 2D arrays. In Monkey C the way you do 2D arrays is to stick arrays in other arrays, so a 25x4 array could require 26 arrays or 5 arrays depending on which direction you create it.

Each string has a dynamic allocation. There is no automatic string collection in Monkey C at this time, so if you are using a handful of small strings many times, you definitely want to stick them in a variable outside of where they are used.

This causes 21 allocations:
var array = [ "a", "b", "c", "a", "b", "a", "b", "c", "c", "a", "b", "c", "a", "a", "c", "b", "c", "a", "b", "c" ];

This only uses 4:
var a = "a";
var b = "b";
var c = "c";
var array = [ a, b, c, a, b, a, b, c, c, a, b, c, a, a, c, b, c, a, b, c ];

In either case, if you are doing something like this with strings, I suggest evaluating if an enumeration might serve you better.

Ok, I've now seen the "widget crash" where the USB connect or fireworks isn't involved. This is a variation of the widget I sent you folks, but it doesn't use GPS, and a fixed station instead. It again crashes when the makeJsonRequest has been issued, and at about the time the data should be back, but before "onReceive" is called. It occurred to me, that maybe there is something messed up in the data the va gets from the phone. Is there any way to trace what's happening in GCM? Does GCM do anything to the data before it's passed on the the va?

What made me think this, is I was walking outside and wanted to see what the temp was, so I started the widget, and I was probably close to the point where my phone was switching from my home WiFi to the cell net for data. Could a "broken Inet" connect cause bad data to be sent to the watch, and the watch tries to convert that, and goes nuts grabbing memory for the bad data?

1907 (vívoactive) SW ver: 290
Build Type: RELEASE
ESN: 3900590391
Battery Voltage: 4.033000V
06/14/15 07:26:40
RTL
errnum: 0x001
r0: 0x20009C98
r1: 0x00000200
r2: 0x000B8B81
r3: 0x00000000
Return Address (LR): 0x000C3791:Call Stack - PSP at 0x200099A8:
0x000C3791
0x0009D40D
0x000DD438
0x001619F4
0x000B8B81
0x000ADA89
0x000B8B81
0x000AD51D
0x0000C000
0x000B7EB1
0x000B8B81
0x000ADDED
0x000B8B81
0x000B8B81
0x000BB865
0x000BBB9F
0x000B56FB
0x0000C000
0x0000F80B
0x000B844F
HWM_usb_connected = 0x00. HWM_usb_mode = 0x01.
SMB config: cfg_start[0]=0x00, cfg_start[1]=0x02, cfg_start[2]=0x06.
page addr = 0x00057009
Uptime: 124275246


Update: after running a few days with FW 3.00 on the va, this crash is no longer happening - looks like it was fixed between 2.90 and 3.00!