• Replies 45 replies
  • Subscribers 20 subscribers
  • Views 8159 views
  • Users 0 members are here
Options
Related

Stack trace addresses in FW.

Alan.raceQs
over 3 years ago

I have been down this path before, but I don't think I ever made sense of the response.

Here's an error log report from my watch yesterday. (Nothing in ERA - it's still reporting "A server error has occurred...")

Error: Out Of Memory Error
Details: 'Failed invoking <symbol>'
Time: 2021-11-18T07:58:17Z
Part-Number: 006-B2697-00
Firmware-Version: '24.10'
Language-Code: eng
ConnectIQ-Version: 3.2.5
Store-Id: 74c474f8-4140-4794-afb7-f56817083bd5
Store-Version: 43
Filename: 4C065B22
Appname: raceQs
Stack: 
  - pc: 0x300035c0
  - pc: 0x300033d0
  - pc: 0x10002946
  - pc: 0x10001256

The first two addresses of the stack trace  (- pc: 0x300035c0 - pc: 0x300033d0) do not lie in my code, so why are they being provided to me as the developer?

I suspect a memory leak in the FW VM as I am, (and have been for the past four years!)  meticulously managing the memory in the app. The crash occurred after 70 minutes of faultless running.

Can anything be deduced from the fact that the first two addresses of the stack trace are in the FW VM?

  • over 3 years ago in reply to Former Member
    they can be caused by something else in the code.

    I'm sure you are correct....the challenge is to identify the "something else".

  • over 3 years ago in reply to subra
    subra said:
    No, it's not the same data that is causing the crash, and it's also different to replay the fit in the simulator. The fit does probably not contain the values that cause the crash because the app terminates before the values are written.

    I have gone to great pains to ensure that it is.

    I'm not only replaying it in the simulator, I'm also replaying it in the watch. As I explained in an earlier post, I have built my own simulator in the app to replay pre-recorded data.

    The app may terminate "before the values are written", but the ActivityRecording continued after the app crashed. The app crashed at 07:58:17Z, but the FIT file continued to record until around 08:08:00Z which corresponds to the time I cleared the IQ! error. So I do have the data from the time it crashed. 

  • over 3 years ago

    This discussion has not really reached a conclusion, so I have updated my original bug report with a summary.

  • over 3 years ago

    I wonder if the answer may be to do with the way MonkeyC handles colliding events, for example callback functions from

    • Position.enableLocationEvents(Position.LOCATION_CONTINUOUS and
    • a timer

    If both functions are non-trivial and the callback from one event is triggered whilst the code from an earlier event is being processed, are both functions consuming memory concurrently?

  • over 3 years ago in reply to Alan.raceQs

    The application code associated with the timer callback and the position callback will be executed synchronously, so this should not be possible.