Wikitude

May not be the the best place to report this and afaik I've only seen it once under the iOS 6.1.0 js sdk but I bought it in the debugger and thought you guys may want to see it. Note the instant tracker was just in the initialization mode when this occurred:

* thread #30, stop reason = EXC_BAD_ACCESS (code=1, address=0x8)

  * frame #0: 0x000000010049f9bc ARExperience`aramis::FlannTree::classifyKeyframe(unsigned char*, int, int) const + 148

    frame #1: 0x00000001004fd59c ARExperience`aramis::Map::classifyKeyFrameCandidates(aramis::Layer<unsigned char>&, std::__1::vector<aramis::KfClassificationResult, std::__1::allocator<aramis::KfClassificationResult> >&, int const&) + 96

    frame #2: 0x00000001004c8a4c ARExperience`aramis::Localizer::localizeWithCandidatesInAllMap(aramis::KeyFrame&, TooN::SE3<double>&, int&) + 1168

    frame #3: 0x00000001004f8d10 ARExperience`aramis::SlamObjectTracker::localize(aramis::BaseLayer<unsigned char>&, TooN::SE3<double>&) + 248

    frame #4: 0x00000001004f96d4 ARExperience`aramis::SlamObjectTracker::run(aramis::BaseLayer<unsigned char>&) + 316

    frame #5: 0x00000001005590dc ARExperience`aramis::MusketIr3dService::processFrame() + 724

    frame #6: 0x00000001005592a8 ARExperience`non-virtual thunk to aramis::MusketIr3dService::internalThreadEntry() + 32

    frame #7: 0x000000010045f794 ARExperience`void* std::__1::__thread_proxy<std::__1::tuple<aramis::ThreadedClass::startInternalThread()::'lambda'()> >(void*) + 88

    frame #8: 0x000000018c5e0850 libsystem_pthread.dylib`_pthread_body + 240

    frame #9: 0x000000018c5e0760 libsystem_pthread.dylib`_pthread_start + 284

    frame #10: 0x000000018c5dddac libsystem_pthread.dylib`thread_start + 4

Full back trace is attached

Actually, I'm afraid I'm not seeing things. I just got the same stack trace on the SDK examples for the 6.1.0 Native SDK running on an iPhone 5s in the debugger. In that SDK I was running the Instant Tracking example. Attached is the full stack trace from that

Its been sort of random but it may be related to looking at effectively un-trackable scenes. I just caught it in the act. It occurred immediately after I pressed start tracking . Attached is a screenshot from the phone where we hit the bad access (to give you an idea of how un-trackable I'm talking about) as well as further detail from the bad access itself

note this is from the wikitude JS 6.1.0 based app running on an iPhone 7 connected to the debugger

I'm able to replicate this quite easily, generally by attempting to track un-trackable surfaces (plain white ceiling).

Hi Andreas,

I've just just several tests (upwards of 30) and no crashes of any kind on iOS (flann tree or otherwise) with this build.

Just as interesting to us I've done another 30-40 tests designed to bring out the deadlock or crashes described in this thread https://support.wikitude.com/support/discussions/topics/5000082387 and I have not been able to cause any of them so this is really very promising!

Definitely! Assuming the rest of the QA process goes well on this pre-release build, do you know when it will be released publicly ?

Thanks again for all your help on these issues Andreas!