• Replies 19 replies
  • Subscribers 18 subscribers
  • Views 5153 views
  • Users 0 members are here
Options
Related

Background processes cannot modify the object store native function

GHG23
My new datafield that I am building has a few early bird users and one of them keeps getting crashes. I have really no idea what this error means, looking at the CIQ_LOG.TXT. My datafield doesn't use local storage, it only takes settings from the property. Like : sAveragePaceSec = mApp.getProperty("pAveragePaceSec");

The Log file (based on a normal version of the datafield, not a special debug version):
"Background processes cannot modify the object store
native function

ERROR: Unhandled Exception
DETAILS: NONE
STORE_ID: 6b9d2d26d7464377830e83422e3df45b
CALLSTACK:
Background processes cannot modify the object store
native function

ERROR: Unhandled Exception
DETAILS: NONE
STORE_ID: 6b9d2d26d7464377830e83422e3df45b
CALLSTACK:
Background processes cannot modify the object store
native function

ERROR: Unhandled Exception
DETAILS: NONE
STORE_ID: 6b9d2d26d7464377830e83422e3df45b
CALLSTACK:
Background processes cannot modify the object store
native function


"
  • The user notified me that removing the app Forecast line worked! He couldn't get my datafield running (https://apps.garmin.com/nl-NL/apps/360a26c4-e2bb-45b7-8f97-2694ccf74eef), so he was happy.
    After that he installed the Forecast line widget again, just to test what would happen, but then my Datarun premium datafield didn't crash. I am a bit puzzled by that......:rolleyes:
  • It could be it takes the crash (what you see in CIQ_LOG) to cause problems for yours, so not only does the background have to run in the other one, it's got to execute the code that causes the crash. It could be the other DF is fixed, and doesn't cause the crash. When yours was crashing, did you have the user reboot their device? Though extremely rare, I recall a case where something got messed up, causing something else to crash, and it stayed that way until the device was rebooted. Then the second app ran fine. I think it had to do with a rogue watchface and was quite some time back...
  • Yup, my app is causing that error, but I do not know why though. Code is quite clear, I only use `getValue`: https://github.com/mrfoto/ForecastLine/blob/master/source/ForecastLineBackground.mc#L17

    And the error I get:
    ```
    Unhandled Exception

    Background: Background processes cannot modify the object store

    Background: onStartBackground: in Background: /Users/mrfoto/Development/workspace/ForecastLine/source/ForecastLineApp.mcBackground: :17
    ```

    So I don't know what to do but to remove this background thingy since it's very unreliable for me and my users :/

    Or is it clear to anyone why would it fail?
  • I took I quick look at the code and wondered if the permission to get coordinates was the problem, but that's arranged for in the manifest file. I don't see an obvious error
  • Check out your code in AppBase, as some of that runs for both the main process as well as the background, and there look to be some code paths when the background may be trying to change Application.Storage. I noticed this in OnStart for example. That's run each time the background runs.

    You can put Sys.println("in Fun X") calls in functions in AppBase, and in the sim's log, it will note if it's coming from the main app or background.
  • Yup, that was it. Thanks, Jim! That was not clear to me that OnStart runs in background as well.

    Now I have to figure out how to detect whether I'm being accessed from background and not do it then ?????
  • There's a trick I use for onStop, but it won't work for onStart or initialize() in AppBase. I have a variable like

    var inBackground=false;

    which I set to true in something unique to the background (getServiceDelegate for example), and then in onStop, check the state of that variable (the variable isn't common to the main app and background). If you find a way to do something like that for onStart(), let us know.

    Maybe you could move your logic from onStart() to initialize() for the view? The view only runs in the main app.
  • I don't think everything is ready and set up in initialize(). I moved it to getInitialView() and looks like it's working :)
  • Former Member
    Former Member
    You can always put your setValue call in a try/catch block, and catch the exception.