Array data size limit?

Thanks! There actualy was a stack also but I do not now how to read that.. :O 

Stack:
- pc: 0x1000435f

Konttorininja said:

Thanks!  "Unhandled Exception" was the error logged.  

Then you may not actually be running out of memory at all (Epix 2 Pro does have quite a bit of available memory for CIQ apps). It's hard to say what the actual error is (the actual exception type is hidden from the crash log on purpose, to avoid possibly leaking user data), but last time I checked, an out of bounds array access is not an exception, but an uncatchable error, so you can probably rule that out.

You should try recreating this in the sim. You can also use the technique in the "Basic Debugging" section of the CIQ debugging docs: create a text log file on the device and use System.println() to write debug information to the file. In the case of the unhandled exception, assuming that the exception details are *not* currently in the crash log, you can catch the exception and print the exception error message using Exception.getErrorMessage().

Additionally, if you use "Monkey C: Build for Device" in VS Code and select Debug, this will produce a debug build of the app that *may* provide further information about exceptions in the crash log. Furthermore, if the regular build is not producing a human-readable stack trace, the debug build *may* do so. (I'm not 100% sure about either of those things tbh, since it's been a while since I tried.)

Thanks a lot once again, I'll add some basic debugging and try to catch what goes wrong.  

There's a link in the "Tips and Tricks" FAQ to help you decode that.

https://forums.garmin.com/developer/connect-iq/w/wiki/107/tips-and-tricks-faq

https://forums.garmin.com/developer/connect-iq/f/discussion/231129/so-you-have-a-ciq_log-file-but-all-you-see-is-pc-without-a-friendly-stack-trace---what-to-do

Wow! Thank you!!

Thanks to your help I did find the issue. Afterall it was not memory related, I just had a typo in one loop which caused null value in one variable. Due to nature of the app that popped up only after few weeks usage.. Lesson learned, always test in simulator. From this on I'll write those functions to populate some dummy data to test all scenarios

dbrobert said:

I frustratingly see a lot of "Unhandled Exceptions" in the ERA for my apps but I also see specifics too (in the past I've seen, off the top of my head: Unexpected Type, Array Out Of Bounds, Too Many Timers, Symbol Not Found, Illegal Frame, Invalid Value, Out Of Memory, Circular Dependency).

Most or all of the specific errors you mentioned are uncatchable errors, not exceptions. I was specifically referring to exceptions (in responding to OP who had a crash due to an unhandled exception). I probably could've made that clearer.

https://forums.garmin.com/developer/connect-iq/f/discussion/193579/era-crash-log-viewer---check-it-out-if-you-haven-t/942192#942192

Travis.ConnectIQ said:

can a developer change the debug.xml content , provoke a crash and get this data via ERA ?

No.

We don't send exception strings or error messages that the developer may manipulate to smuggle data off of the device. We sell these devices in Europe, so we are bound by GPRD to not send anything that could be used to personally identify anyone.

We currently capture the following data when a crash occurs:

• time/date of the crash
• device part number (this tells us what device model was used, this is not the unique device id)
• device firmware version
• active language
• ConnectIQ SDK version used to build the app
• ConnectIQ app store id (to identify the crashing app)
• ConnectIQ app store app version
• name of the .PRG file that crashed
• name of the app that crashed
• stack trace of the crash
• the crash type (out-of-memory, symbol not found, ...)

The entire crash log is uploaded, but some of this data is not used by the ERA system. For example, the PRG and app name are there to help users locate and eliminate problem apps on the device and is not useful in reporting crashes via the ERA service.

FlowState said:

Most or all of the specific errors you mentioned are uncatchable errors, not exceptions.

Ah, good point. However, in looking at Travis.ConnectIQ's post, he mentions not sending exception strings or error messages, not the exception class itself. The strings make sense since one could "leak" privacy/personal info in the message but I'm not seeing how any privacy data leaks could be done using an exception class name.

dbrobert said:

I'm not seeing how any privacy data leaks could be done using an exception class name

That's a good point but I don't think class names are available at runtime.