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

jim_m_58

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

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:

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.

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.

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.

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?

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.

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.

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.