Symbol Not Found Error - CALLSTACK: @PC=0x0000000

you're probably referring to the invalid value thread I started a while ago, where I also had that 0 callstack behaviour. In my case it turned out to be a division by zero during my draw routine.

To track this error down I created a "DO NOT APPROVE version of my app" (to be able to upload this version you will have to chance the manifest, you can't upload 2 apps with the same id) where I added System.println(" "); statements at strategic locations + created a <myprogid>.txt file in the log folder.
When the data field crashed I could go have a look in the txt file and narrow down the location in my code, after which I would remove/add more System.println(" "); statements, a matter of interpolation ;)

Be aware that the System.println(" "); statement in something which occurs often (eg compute / onUpdate) slows down the heck out of your app... so be prepared for some lag :)

This is on my own device I'm seeing it so no need to deal with the store.

I've been adding println's all over the place. It seems to be happening in random locations, often mid way down one of my routines (I've got prinln's for entering/exiting a function). This assumes that once I've done a Sys.println, the text actually gets written to the app.txt log file. If there is any caching going on here, all bets are off with my diagnostics.

I've up'd my HttpRequest's to be called every second if there is no pending request, ie if I've already got the response from the previous one, so only one outstanding request at a time. With this, I can get it to crash within a couple minutes.

If I don't start recording an activity, the problem doesn't seem to happen. But upping the HttpRequest frequency, definitely gets it to happen quickly. Doesn't seem to matter if GPS is enabled or not.

Not sure if this helps at all, but I'm getting the following error text in the ERR_LOG.TXT file in the device root folder:

2156 (Forerunner 630) SW ver: 710
Build Type: RELEASE
Commit:1bcef5c212eb9f98292ccd1d9b7ff1dbf9457258
ESN: 3913937793
02/23/17 07:23:17
RTL
errnum: 0x00f
r0: 0x2003e0b0
r1: 0x000f757d
r2: 0x00000818
r3: 0x000000b7
r4: 0x00016128
Stack frame PC, SP: 0x0013597d, 0x2003dec0
Call Stack - SP at 0x2003dec0:
0x000507f1
0x000fcc2b
0x0010c869
0x000f757d
0x000f757d
0x000023fd
0x000f757d
0x0010cc61
0x000f757d
0x0010c0a7
0x000f757d
0x000f632d
0x000f666d
0x0004000d
0x0010b661
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
Uptime: 333713

Could someone from Garmin comment on the likelihood that this is in system code vs my code? I wouldn't say it is reproducible on demand but I can generally get it to crash within a couple minutes. I'm pretty sure it's not directly in my code. Happens in random locations but pretty sure always while waiting for a response from an HTTP request and I only know I've seen it while recording an activity. Not sure how the low level stuff works here but could it be while handling an interupt when a HTTP response is received?

Only Garmin folks can give you info from the err_log.txt, but from what you describe, maybe a memory condition when the response to your data request is being processed? How much data are you getting back (max) and how large is your app (peak in the sim) ?

Jorge zona

shouldn't be a memory issue. The entire response is as follows.

{"ws":["66","62","65","62","23","24","48","49","15","13","34","76","469762048"]}

Already reduced it to a predefined array of values from originally being a dictionary, in order to simplify the parsing. Also happens on debug and release builds alike. For release build, the max mem I see is about 53k. Debug build is 56k. There is definitely a timing component involved here.

One other note is that if I'm pressing buttons, it seems to increase the chance of crashing, but it also can happen with no button presses.

Hey all,

I'm not 100% sure on this one yet, but I think it's likely a device side issue. I was able to parse the error log and pass it on to the 630 team to investigate.

Thanks,
-Coleman

Hey all,

I'm not 100% sure on this one yet, but I think it's likely a device side issue. I was able to parse the error log and pass it on to the 735XT team to investigate.

Thanks,
-Coleman

thanks for following up. Just to be clear, this was on a fr630.