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
Could you explain in more detail how the scene looked like that you wanted to track/initialize?
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).
Thx for reporting the issue. We're currently working on a fix which will likely be available as a pre-release version soon.
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!
That's great news! I'm happy that this build resolves some issues for you.
In case you encounter something new, please don't hesitate to contact us.
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!
The next public release is also our next major release. I can't mention any exact date yet, but AWE is coming soon ;)
The last build you received is 6.1.0 including only some instant tracking and smaller Android adjustments, so if the next public release of our SDK is too far away for you I would say that you could release with the build you received yesterday.
I need to say thank you for reporting all these issues and thereby helping us improving the quality of the Wikitude SDK!