No announcement yet.

App randomly dies when using vuforia

  • Filter
  • Time
  • Show
Clear All
new posts

  • App randomly dies when using vuforia

    We just came off of 2 incredibly frustrating tournaments where the RC app would suddenly die while in waitForStart() with no useful hints as to why. If it lasted long enough for us to hit start then the program worked fine without crashing. One of the tournament techs found a possible workaround by moving a call to runtime.reset() that we were making just after waitForStart() to just before it. I haven't tested that, so I don't know if it that fixes it for us. Even if it does, it is not at all satisfying since it leaves the underlying bug, ready to bite us again in the future. A log of the crash is pasted below. It looks like the bug may be in the Vuforia library. I saw another post where they claimed communication was lost and they just needed to update telemetry while in waitForStart(). I don't think that is our problem since the app completely dies and we have to manually restart it.

    I'm wondering if anyone else using vuforia has seen this type of crash or has some clue as to what's going on? These kids worked so hard and were so disheartened by this issue that was completely out of their control. It would be nice to be able to give them some explanation as to what was wrong. The full java program can be found here:

    and from the log:

    --------- beginning of crash
    12-09 14:29:35.132 8217 8141 F google-breakpad: Microdump skipped (uninteresting)
    12-09 14:29:35.172 2780 8141 W google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
    12-09 14:29:35.172 2780 8141 W google-breakpad: Chrome build fingerprint:
    12-09 14:29:35.172 2780 8141 W google-breakpad: 71.0.3578.83
    12-09 14:29:35.172 2780 8141 W google-breakpad: 357808300
    12-09 14:29:35.172 2780 8141 W google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
    12-09 14:29:35.173 2780 8141 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x90cc5014 in tid 8141 (FrameManager)

  • #2
    Can you post the full log? Furthermore, it will be easier to debug if we know the answers to the questions here. You may also want to attempt moving the waitForStart() method from TriRobotInit() to runOpMode(). My team has experienced some problems with using the inherited functions of LinearOpMode in anything other than runOpMode(). Maybe worth a try.


    • #3
      Attached is the last 195 lines of the log (largest attachment I can add).

      Moving the waitForStart() is a good idea to try. Thanks for the suggestion.

      Another thing I think we will try is moving the VuforiaLocalizer and TFObjectDetector objects to exist only in the scope of the FindGold method. It looks like the camera image is showing up on the Robot controller App when we hit Init even for a version of the opMode where we moved the iniVuforia and initTfod to be after waitForStart (at least I think I remember it doing that). I'm not really a Java expert and am more of a C++ guy, but I can imagine having the VuforiaLocalizer object as a member causes it to instantiate as soon as the opMode is instantiated. If it launches a separate thread to feed the camera images to the app's screen then maybe that thread is crashing in parallel to the one running waitForStart (??). Maybe minimizing its scope will help. I'll let you know if I make any progress.
      Attached Files


      • #4
        Oddly, I seem to be unable to recreate the problem. I noticed that the log seems to indicate that you do not have the most recent version of the rev hub firmware. You may want to update it. I recommend doing it through RevHubInterface, which can be found here. Hope this helps!


        • #5
          Thanks for the tip on the REV. I'll take a look at updating the firmware (just have to find a Windows PC!)

          For anyone else who is interested, I tried moving the VuforiaLocalizer and TFObjectDetector references to exist only in the scope of the FindGold method. I ran it twice without crashing, each spending at least 10 min spinning in waitForStart(). I can't say if this really fixes it, but it is at least promising.

          I did confirm with a Java expert that the references in the class are not actually causing the objects to be instantiated when the linearOpMode object is. This is different from C++. I'm not sure why it seemed like we had a crash when the instantiations were moved to after waitForStart() unless we fooled ourselves and were really running an older opMode.

          One lesson I definitely take from this is to try and do more "tournament style" testing if possible. The reason this problem never really presented prior to the tournament is because as we tested the autonomous, we never paused between tapping Init and Start. There was never really any need to during practice. During a tournament however, it is very normal to have to tap Init and then wait 5 minutes before you're told to tap Start.


          • #6
            Any chance you are using Moto E4, Moto G5, or Moto G5 Plus phones? If so, see:



            • #7
              Just an update that reducing the scope of the VuforiaLocalizer and TFObjectDetector object references seemed to do the trick. Instead of using object scope references, we used references only in the method that is called to find the location of the gold. Everything finally worked as designed and we ended up the 2nd ranked team at the Charlottesville tournament last weekend. This doesn't actually fix the bug, but at least it quarantined it someplace where it no longer affects us.

              Oh, and we are using Moto G4 Play phones.