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

Help interpreting crash results.

Alan.raceQs
I managed to capture one of the crashes of my app yesterday, but am none the wiser for it, so am looking for some inspiration.

The CIQ_LOG.txt file reports
ERROR: Unexpected Type Error
DETAILS: Failed invoking <symbol>
STORE_ID: 00000000000000000000000000000000
CALLSTACK:
C:\alan\projects\raceQsGarmin\raceQs\source\engine.mc (sendLogs:905)
C:\alan\projects\raceQsGarmin\raceQs\source\engine.mc (dispData:1101)
C:\alan\projects\raceQsGarmin\raceQs\source\engine.mc (GPSData:808)


sendLogs:905 is here, highlighted in red:
if (logMarksArray.size() > 0){
var replayWptString;
for (var i =0; i< logMarksArray.size(); i++){
replayWptString = "P";
for (var j = 0; j<logMarksArray.size(); j++){[/COLOR]
replayWptString += ","+logMarksArray[j];[/COLOR]
}
replayWptString += ";";
unloadTrackString += replayWptString;
}
logMarksArray = new [0];
}[/CODE]
I don't have the log file for that time as I was in the midst of a race and had to restart the app which then ran fine for another hour (till it crashed again, but that's another story) so the .BAK file got overwritten .

I'm trying to understand what could generate the " Unexpected Type Error" reported on line 905.
If logMarksArraywas anything other than an array, I would get
ERROR: Symbol Not Found Error
DETAILS: Could not find symbol size.

Sometimes the line reference in the error log is refers to the line before the faulty line, so I look at line 906, highlighted blue but can't figure what condition could cause the error.

This code block is executed every 30 seconds, so it's far from being an obscure piece of code that gets executed infrequently, and it only crashed after around 40 minutes of normal running.

Since the crash is intermittent, and I'm not able to replicate it "in the lab", any constructive suggestions for strategies to capture the cause will be greatly appreciated.

Running on VA-HR
  • Heh, yeah... The one thing I have learned is that there can be a whole ton of not so clear errors in connectiq and debugging them really is nasty (as I have had multiple occasions with the emulator working fine but things crashing on the watch).

    But we learn every day ;) Glad it seems figured out now!
  • One thing that's helpful with stuff like this, but only in the sim, and it just came out in 2.3.0.beta1, is the debugger.

    Set breakpoints, look at things, step through problem areas, etc. Been using it some as I adapt watch faces for 1hz and experimenting with background processes.

    I'm hoping 2.3.1 gets released soon so I can start putting 1hz watch faces in the store!
  • One thing that's helpful with stuff like this, but only in the sim, and it just came out in 2.3.0.beta1, is the debugger.

    Set breakpoints, look at things, step through problem areas, etc. Been using it some as I adapt watch faces for 1hz and experimenting with background processes.

    I'm hoping 2.3.1 gets released soon so I can start putting 1hz watch faces in the store!


    Yeah, debugger does help... Still seems very rudimentary but tons better then all the System.println stuff.

    Can it hurt to do most of the development in the 2.3.0 beta1 sdk and switch back to 2.2.5 for publication only? (As the beta doesn't support export of the app, which is needed to publish new versions and apps).
  • One thing that's helpful with stuff like this, but only in the sim, and it just came out in 2.3.0.beta1, is the debugger.

    Set breakpoints, look at things, step through problem areas, etc. Been using it some as I adapt watch faces for 1hz and experimenting with background processes.

    I'm hoping 2.3.1 gets released soon so I can start putting 1hz watch faces in the store!

    hey Jim, not sure whether you also experience this behaviour, when debugging the initialize function, it only seems to show something in the variables window as of the 2nd breakpoint for me...
  • hey Jim, not sure whether you also experience this behaviour, when debugging the initialize function, it only seems to show something in the variables window as of the 2nd breakpoint for me...


    I've not noticed that, but maybe do a bug report?
  • Yeah, debugger does help... Still seems very rudimentary but tons better then all the System.println stuff.

    Can it hurt to do most of the development in the 2.3.0 beta1 sdk and switch back to 2.2.5 for publication only? (As the beta doesn't support export of the app, which is needed to publish new versions and apps).


    Actually, you'll probably want to have two eclipse environments as the plugins are pretty different. That's how I'm set up right now.

    And there is a 2.2.6 SDK, but the only real change is the support of the Q5 (it will include it in the .iq for the app store). In the sim, it's just like the F5.

    I'm hoping that 2.3.1 comes out soon, so there will no longer be a need to switch back to publish. (I'm just maintaining the 2.2.6 environment in case I find bugs to fix before 2.3.1) Doing a 1hz WF but building with 2.2.6 has a few issues depending on your code, but it can be done, and for me 1hz has to be fully disabled in the code - easier to have the non 1hz version in 2.2.6, and the 1hz version in 2.3.x)
  • I'm hoping 2.3.1 gets released soon so I can start putting 1hz watch faces in the store!
    Hey Jim, hoping it is ok to hijack this thread, but there are already 1hz watch faces in the store. So, although the SDK may not be released yet, it appears you can publish now. I'm running Line which uses a background process to get weather and has seconds on all the time.

    Have to say, the 1Hz watch faces are great. As much as I liked many of the CIQ watch faces on my fenix 3 and 5X, I tended not to use them since I really missed the seconds. But now I have seconds the one thing stopping me using them all the time is gone.
  • Actually, you'll probably want to have two eclipse environments as the plugins are pretty different. That's how I'm set up right now.

    And there is a 2.2.6 SDK, but the only real change is the support of the Q5 (it will include it in the .iq for the app store). In the sim, it's just like the F5.

    I'm hoping that 2.3.1 comes out soon, so there will no longer be a need to switch back to publish. (I'm just maintaining the 2.2.6 environment in case I find bugs to fix before 2.3.1) Doing a 1hz WF but building with 2.2.6 has a few issues depending on your code, but it can be done, and for me 1hz has to be fully disabled in the code - easier to have the non 1hz version in 2.2.6, and the 1hz version in 2.3.x)


    Fair enough! I have now set it up like that... One with the beta sdk and one with the final version. I now have shared the projects (source and resources and all) though, don't think that should be an issue? (Unless experimenting with new code of course).

    Dunno what the easiest/most manageable way would be, creating copies of the projects doesn't sound too great. Any tips, do's and don'ts regarding that?