• Replies 22 replies
  • Subscribers 21 subscribers
  • Views 1316 views
  • Users 0 members are here
Options
Related

Array data size limit?

Konttorininja
1 month ago

Hello guys!

I have two dimensional array with fixed size (15x100). Empty slots are filled in order with strings containing 16-17 chars. In same stage when storing values the app crashes. So far I have not been able to reproduce this in simulator. 

i’m just wondering what is the data size limit of an array? Might that be the issue? 

is there any way to debug in watch?

Thanks!

  • 1 month ago in reply to jim_m_58

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

    Stack:
    - pc: 0x1000435f

  • 1 month ago in reply to Konttorininja
    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.)

  • 1 month ago in reply to FlowState

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

  • 1 month ago

    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 Slight smile

  • 1 month ago in reply to FlowState
    FlowState said:
    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)

    Do you have a reference to back this up, ? 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).

  • 1 month ago in reply to dbrobert
    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.

  • 1 month ago in reply to FlowState
    FlowState said:
    Most or all of the specific errors you mentioned are uncatchable errors, not exceptions.

    Ah, good point. However, in looking at '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.

  • 1 month ago in reply to dbrobert
    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.