Retain state data over a crash.

I am retaining my app's state data using AppBase:setProperty which is working fine, and this data is being retained over successive app starts.

However, when the app crashes, the new state data is not being retained and an app restart will retrieve the same state data that the last app start retrieved.

It seems that the state data is only actually being written to a truly persistent object store when the app closes gracefully.

If this is the case, is there any way for the app itself to save the state data to the object store on a periodic basis to enable it to be restarted after a crash with the last saved state?

(Obviously, this wouldn't be an issue if the app didn't crash, and believe me, I'm working hard to track down the elusive bugs, but meanwhile...)

jim_m_58 over 8 years ago

You can pose this to Brandon et all, but I think it's safe to say that even if your app has a warning in a 100 pt red font, it is something no one wants attached to CIQ apps in general. ("up to the user" lasts as long as they remember reading the warning - if they even read it at all! :) )

Aren't you saving your current data in a .fit?

travis.vitek over 8 years ago

I still don't understand why it's not a great idea.

I'm sure one of the Garmin guys can elaborate, but if I remember correctly there was some concern at one point that writing to data frequently was going to cause issues with the longevity of the flash storage.

As I understand it, you have an app that crashes intermittently and you're trying to find a way to avoid losing data when this happens. I can totally understand how this can be frustrating. But, by making this functionality available again, Garmin would essentially be supporting developers producing and publishing apps that crash. That seems like not a great idea, at least from the perspective I believe Garmin is likely to be looking from.

If you'd like help trying to figure what is going on with your application, I'd be happy to take a look at it with you.

Travis

Alan.raceQs over 8 years ago

Yes, thanks, but my problem is a tad intractable!

It won't crash for me, either in the Sim, on the watch during land testing or on the water in actual racing conditions, but it does for my alpha tester, and then only very intermittently maybe once an hour when he's on the water and then only once or twice a week if I'm lucky! And he's in San Francisco, 12,000 Km from me in Sydney!

I'm working on 2 fronts:

to test some of the more subtle features that only he can do as he's a more experienced yacht racer than I am, and he can only really do that in the heat of battle - during a competitive race, and
to fix the crash.

In order for 1) to work he needs to be able to restart after a crash, so I need to be able to restore his state.

In order to debug 2), I only have his his CIQ_LOG which unfortunately provides no clue as to where the crash occurred, and data that I save to the logging file gets overwritten by the app!

So thanks for the offer, I can send you an archive but I don't think you'll be able to help as I have no idea where the cash occurs.

travis.vitek over 8 years ago

I only have his his CIQ_LOG which unfortunately provides no clue as to where the crash occurred, and data that I save to the logging file gets overwritten by the app!

Are you providing him with a debug build? The data from CIQ_LOG.txt should be more useful with a debug symbols.

As I understand it, the application log file shouldn't get overwritten immediately. According to the system outlined in the New Developer FAQ #8, the application log file should be rotated out and you should get up to 10KB of data. Perhaps there is too much data being logged?

Alan.raceQs over 8 years ago

CIQ_LOG.txt should be more useful with a debug symbols.
Anything would help, all I'm getting is:
ERROR: Symbol Not Found Error DETAILS: Failed invoking <symbol> STORE_ID: d76bf3e20924470eb86b62f372ecc0ae CALLSTACK: @PC = 0x00000000 ERROR: Unhandled Exception DETAILS: NONE STORE_ID: d76bf3e20924470eb86b62f372ecc0ae CALLSTACK: WARNING: Error in positioning callback STORE_ID: d76bf3e20924470eb86b62f372ecc0ae
Is there something I can add to make it more useful? Even a timestamp would be helpful! Have I missed something else in the doco about a debug build?

and you should get up to 10KB of data. Perhaps there is too much data being logged?

I get about a page of data in each of the files. since I don't know what to log, I have to log a lot, and since he has to restart the app after the crash to continue testing the subtle stuff, then I lose the good stuff:mad:.

travis.vitek over 8 years ago

Is there something I can add to make it more useful? Even a timestamp would be helpful! Have I missed something else in the doco about a debug build?

I don't know if it is in the docs or not, but when you build for a device, you'll notice a scrollbar on the right of the build dialog. If you scroll to the bottom there is a checkbox that allows you to enable or disable debug symbols. I don't recall what the option is actually called and I don't have the SDK installed on my work PC so I can't startup Eclipse to have a look. Maybe someone will post a screenshot for us (Jim?)

Travis

jim_m_58 over 8 years ago

Since he's got a store ID in the CIQ_LOG. txt, that' saying it was installed from the app store and is a release build.

For a build with debug symbols, you need to send a sideload (if setting are used, you can also send the related .set).

Running a sideload with the debug symbols will give you more info in the ciq_log.txt (it could be down to line number and variable involved)

Here's where you uncheck for a build with debug symbols. Then email the .prg to the user. (have them uninstall the store version first)

Alan.raceQs over 8 years ago

Yes, but what does it do?

Brandon.ConnectIQ over 8 years ago

Annnd... I see Jim beat me to it, and upstaged me with a screenshot. Well, I'm leaving this here for posterity. :P

@RaceQs: Try building a development/debug build like Travis suggested. It will decode the PC numbers into file and line numbers which should give you a better idea of where the error occurs. Since the PC value in your snippet is 0x00000000, it doesn't tell us anything beyond the "symbol not found" error.

To build a debug build, go to the Connect IQ menu in Eclipse, choose Build for Device Wizard, then choose your project, the device your alpha tester uses, etc., and click Finish. That will output a single PRG file for the target device, which your alpha tester can side load directly to the device (they won't be able to use the app store to install). The next time he's using the app and it crashes, it should give a little more info to go on. The only drawback to debug builds is that they can suffer some hit in performance because of the additional logging, but that's normal and does not reflect release build performance.

I suspect saveProperties() won't make it back into the API. I can ask about it, but since it was never intended to be part of the API in the first place, it's unlikely we'll re-introduce it.

jim_m_58 over 8 years ago

Brandon - I can be quick with that alt-PrtScr! :)