• Replies 28 replies
  • Subscribers 20 subscribers
  • Views 6486 views
  • Users 0 members are here
Options
Related

ERA/Crash Log Viewer - check it out if you haven't!

jim_m_58
over 5 years ago

This is something new in the CIQ 3.1 SDK, and is really useful!

See https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/exceptional-crash-logging

When one of your app crashes on a user device, the CIQ_LOG file is automatically uploaded to garmin, and using the debug.xml (which is automatically included when you build a .iq for the store) you can easily see the crashes users are having.  It's a summary, so you can see "this is something that happened X times, on these devices, with this firmware", with actual line numbers in a stack trace and not just the PC values!

Be forewarned, that the first time you use it, you may find things that you've never heard about - the app crashes, and there's no bad review or "contact developer" about it. That happened to me just today (I'd updated an app just a couple days back).  I had a crash in an app, and the only way I knew about it, was by looking at the crash log viewer in eclipse, and the bug was easy to find and fix based on the info provided!

  • Former Member
    Former Member over 5 years ago

    could you give it a quick check, that no sensitive info is send

    wild thoughts from a worried Garmin CIQ user

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

    is sending ERA data coupled to a consent given by the users ?

    ...

    (am not a developer, so am not getting a notification about updates to this post !!!)

    happy & safe sporting

  • over 5 years ago in reply to Former Member

    There is noting in the crash log that IDs a user.  It's the same info that's in the ciq_log file on a watch, but with the debug.xml file used to convert PC addresses into lines of code in the app.  All that a dev can see is "this crash happened X time on these devices (f6, va3, etc)

    I'd guess uploading the file is related to the checkbox about allowing debug info being sent to Garmin, and garmin has covered any privacy issues.

    Here's an example of all a dev can see:

  • over 5 years ago in reply to Former Member
    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.

  • over 5 years ago

    Very useful post.  I will say the viewer is very nice when you get something out of it, but I'm not getting consistent functional behavior.

  • over 5 years ago in reply to Alex

    Here's what may have happened:

    Say you had 3 different crashes in the log for your app.  You fix the first one, and update the store with that fix.

    The crash logs are reset because there's a new version in the store, and the crash log viewer only shows crashes for the latest version, so when you look, you don't see any crash logs.

    You want to fix them all before you update the store.  That way you don't lose any crash logs.

  • over 5 years ago

    ERA is very usefull, I've been using it since it's been on BETA, no need anymore to "run" after Crash Log from users,

    very efficient, just have to check the line without any conversion.

    This is very efficient add for devs, a huge time saving !

    very easy to use.

    May be someone can help me, I added a beta version only for me, and they had been deleted since but they still show up in ERA, can I remove them?

  • over 5 years ago in reply to jim_m_58

    @jim_m_58 This is extremely useful information that should be extremely obvious when you're in the tool.  May I ask what percentage of crashes actually should show up in the tool?  I've seen 1 and been reported several issues.  People tend to leave bad reviews without any follow up information.  It would be nice to be able to see their crashes but I don't.

  • over 5 years ago in reply to Alex

    It kind of depends on how many apps you have and how long they've been in the store without an update.  If the app has only been in the store and there aren't many downloads, you wont see as many.  I know in my case, I definitely saw some in the crash logs that I've never heard about from users.

  • over 5 years ago

    Is anyone else seeing backtraces in the ERA that are plainly incorrect, e.g. functions that do not call each other listed as if they do?

    Either the PC-to-Line-Number mapping is somehow out of sync, or there are multiple 'thread' contexts interleaved, or something...no idea.

    Also seeing quite a high number of 'non-actionalable' errors, like 'File Not Found Error'. Guess it's better to see them, but frustrating that there isn't a clear fix for those--that I know of at least.

    Other than, great tool.

  • over 5 years ago in reply to rconradharris

    For me line numbers this matches for me. Can you elaborate with some code pieces?

    As to non-actionable errors, sometimes the ways of era can be indeed mysterious, I'm also biting my teeth on some hard to understand reports.