Stack trace addresses in FW.

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?

  • If you do collect GPS locations, that's something to look at.  I have a large array where I save locations every minute, and when it gets full (it takes hours), I switch to every 2 minutes and so on, so I never grow the array/

    If you do something like array.add() to grow the array, you use a whole munch of memory for that operation, as a new array that's needed for the increased size gets allocated, and the old array's info gets copied over, so for a time, you use double the memory for the array.

  • And System X vs System 5 is coming. with the 4.1.0-beta1 and associated devices, there are System 5 preview devices for both the Venu2 and fenix6 pro.

  • If you do something like array.add() to grow the array, you use a whole munch of memory
    1. I know.
    2. I don’t .
    3. If I did, the error would have replicated in the test procedure I described above.
  • I'm pretty sure if there was an incompatibility in the VM versions that the crash would not be so difficult to replicate.

    OK, unfortunately my comment doesn't solve your issue.

    "Error: Out Of Memory Error" may be not only an overflow of the memory, but in general a reference to an address outside the memory. This is also possible due to uninitialized variables or myArray[-1] or myArray[null] or ...

    You know the pc address of the error. It may be helpful to analyse the critical code section around the pc address by either

    1. primitive debugging like this
    if(myVarible == null || myVariable > 1000 || myVariable < 0) {
    System.println("function myFunc: myVariable = " + myVariable);
    System.exit(); // to prevent huge output
    }

    2. an exeption handler like this
    https://developer.garmin.com/connect-iq/api-docs/Toybox/Lang/Exception.html

    3. monkeyC test module like this
    https://developer.garmin.com/connect-iq/api-docs/Toybox/Test.html

  • 3) Maybe not as memory allocation can be different (OS level)

    2) try doing an add() 8 times in a row. 

  • "Error: Out Of Memory Error" may be not only an overflow of the memory
    3) Maybe not as memory allocation can be different (OS level)

    Guys, thanks for your input, but you're missing the point.

    In all your scenarios, the crash causes you are considering would be reproduced in the testing regime I have described.

    It isn't. I have spent countless hours replaying the data through my code.

    The whole point of my issue is that the same data, run through the same code not only fails to cause an "Out Of Memory" error, it clearly demonstrates absolutely no increase in memory usage through the 70 or so minutes of simulation.

    I am looking for a deeper issue that is causing the pain.

  • When you recorded the data that you are playing back, were you using smart recording?  If so there's less data in the fit than will be seen of a real device, as there lat/lon is always seen every second, even if smart recording only saves it every few seconds.

  • Former Member
    Former Member over 3 years ago

    Bugs like this can be difficult to find because they can be caused by something else in the code.

  • The whole point of my issue is that the same data, run through the same code not only fails to cause an "Out Of Memory" error, it clearly demonstrates absolutely no increase in memory usage through the 70 or so minutes of simulation.

    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.

    Nevertheless it's a good idea to look into the fit to analyze what happens shortly before the crash at the end of the fit. Using the FitCSVTool you may convert the fit into csv and also filter some data of interest and output them. But it may be that the tool complains about the fit is corrupted due to the crash.

    As you mentioned, the error occurs randomly. The program flow in the app usually depends on the data. So it may be that the data randomly are wrong or unusable and this triggers the crash.

    I assume that the app uses some sensor data, such as GPS. I suggest you to carefully check if your app is processing the GPS data correctly, even if the GPS signal is lost or poor or interrupted or unusable due to multipath, etc.

  • When you recorded the data that you are playing back, were you using smart recording? 

    Yes. But interestingly, the recorded data shows occasional missed "beats". And I mean very occasionally, and without a pattern I can detect.

    Usually only a single second is missing, but there are occasions where two or three seconds are missing from the record.

    But, and I think this is important, this is not only occurs in tracks that caused crashes, it appears in all the hundreds of tracks I have examined.