Systemic CIQ Crash

I've never seen this behavior before. I made a last minute change to my RaceGauge data field. A simple error - in an if statement I checked if var > 0 and forgot to first check if var == null. Anyway, on my ride it crashed and instantly every other CIQ app, mine and 3rd party, all crashed. I rebooted my EDGE 1050. Same thing. Tried several times. Weird. That a data field's crash propagated to the entire CIQ subsystem. Is this an EDGE 1050 firmware bug or have you seen this kind of systemic CIQ fault propagation on other devices?

FlowState 3 days ago

No, I haven't seen a general (*) case where one CIQ data field's crash causes all other CIQ data fields to crash, but I've never tested on a real Edge, only watches. On watches, there have been annoying issues where adding certain CIQ fields in a certain order would cause the 2nd one to crash, but that's not really the same thing as what you're talking about.

(*) I am aware of a well known specific issue where two CIQ data fields can combine to cause a crash if they collectively try to write too many FIT fields (since there's a limit on developer FIT fields which applies to the entire activity). This is often seen when using the Stryd Zones data field (which writes several FIT fields) with another CIQ data field which writes FIT fields. It's enough of an issue that Stryd support just recommends not using any other CIQ data field at the same time as Stryd Zones. (Yeah, we've probably both talked about this annoying limit a few times in the forums.)

In order to further investigate (if you're truly interested), why don't you try testing your buggy CIQ field with a 2nd CIQ field of yours? If and when they both crash, you can see whether the 2nd field produces a crash log, and if so, what the contents are. That way you'll have some additional ammo for a bug report. (Yes, this sounds like a bug to me. It may very well be by design, but I would file a bug report anyway, so you could at least get confirmation.)

peterdedecker 3 days ago

it shouldn't but apparently it does, test if you can still replicate, create a bug report and attach the prg file which causes it.

DaveBrillhart 3 days ago in reply to peterdedecker

will do

DaveBrillhart 3 days ago in reply to FlowState

Curiously, several of the 3rd party fields all produced entries in "CIQ_LOG.YML" all with the same Program Counter value. That might be the common entry point address for all fields? All were triggered at the same timestamp. Here is one of a handful of fields that aborted at the same time as the "null value" bug in my field. Weird!

Appname: 'Xert: Focus and Strain'
Stack:
- pc: 0x10000270

FlowState 3 days ago in reply to DaveBrillhart

That's pretty interesting, but again, if you install a 2nd CIQ data field that belongs to you, you may see additional information in the crash dump (such as a proper stack trace), which may be helpful to Garmin and/or help satisfy your own curiosity.

It's up to you ofc

DaveBrillhart 3 days ago in reply to FlowState

I had another of mine running (the one in the OP image called Dashboard). Strangely while it also crashed, the only entries in CIQ_LOG were the offending field (mine) and several of the 3rd party fields. My other field I own didn't send any diag info to CIQ_LOG.

FlowState 2 days ago in reply to DaveBrillhart

Try setting up an activity with only 2 CIQ fields: the one that causes the crash and a 2nd one of yours.

The idea is to set up the simplest possible situation that recreates your problem: both for the sake of simplicity itself (e.g. for Garmin to duplicate your problem) and to eliminate any possible confounding factors (like the fact that your field apparently isn’t writing a crash log — could be bc so many fields are crashing at the same time)

DaveBrillhart said:
(the one in the OP image called Dashboard)

You realize we can't tell the names of any of the crashed CIQ fields by looking at the screenshot, right (besides the one in the literal crash dump)