Start a new topic
Solved

Possible deadlock in 6.1.0 with instant tracking / transparent video

So I'm still investigating whether this is due to my code or Wikitude, and its very difficult to replicate (often happening less than 1/10 runs) but I'm seeing deadlock / stall on the main thread when deallocating my ARViewController .


I didn't see this prior to 6.1 . The structure of the app is the ARViewController is in a UINavigationController so when the user presses back in the nav bar everything goes away.


The structure of the experience is a transparent 2d video is playing on an instant trackable


Anyway, the stack trace I'm seeing on the main thread is this


* thread #1: tid = 0x3aafd, 0x000000018c51a314 libsystem_kernel.dylib`__semwait_signal + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

  * frame #0: 0x000000018c51a314 libsystem_kernel.dylib`__semwait_signal + 8

    frame #1: 0x000000018c5e5b40 libsystem_pthread.dylib`pthread_join + 552

    frame #2: 0x000000018bf497fc libc++.1.dylib`std::__1::thread::join() + 28

    frame #3: 0x0000000100521690 ARExperience`aramis::Reactor::~Reactor() + 92

    frame #4: 0x00000001005217c0 ARExperience`aramis::Reactor::~Reactor() + 12

    frame #5: 0x00000001005e3ed8 ARExperience`aramis::MusketIr3dService::~MusketIr3dService() + 84

    frame #6: 0x00000001005e3fac ARExperience`aramis::MusketIr3dService::~MusketIr3dService() + 12

    frame #7: 0x0000000100447284 ARExperience`wikitude::sdk_foundation::impl::MusketIr3dService::~MusketIr3dService() + 336

    frame #8: 0x0000000100447434 ARExperience`wikitude::sdk_foundation::impl::MusketIr3dService::~MusketIr3dService() + 12

    frame #9: 0x0000000100444ac4 ARExperience`wikitude::sdk_foundation::impl::ServiceManager::unregisterService(wikitude::sdk_foundation::impl::ServiceIdentifier const&) + 220

    frame #10: 0x0000000100430510 ARExperience`wikitude::sdk_foundation::impl::IrService::removeTracker(wikitude::sdk_foundation::impl::BaseTracker&) + 192

    frame #11: 0x0000000100454fa4 ARExperience`wikitude::sdk_foundation::impl::BaseTracker::~BaseTracker() + 136

    frame #12: 0x0000000100429260 ARExperience`wikitude::sdk_foundation::impl::InstantTracker::~InstantTracker() + 172

    frame #13: 0x00000001004292dc ARExperience`wikitude::sdk_foundation::impl::InstantTracker::~InstantTracker() + 12

    frame #14: 0x0000000100634de0 ARExperience`wikitude::sdk_core::impl::InstantTrackerInterface::deleteObject(wikitude::sdk_foundation::impl::ArchitectObject*) + 72

    frame #15: 0x00000001006d7e34 ARExperience`wikitude::sdk_core::impl::ArchitectEngine::destroyObject(wikitude::sdk_foundation::impl::ArchitectObject*) + 124

    frame #16: 0x00000001006d79a0 ARExperience`wikitude::sdk_core::impl::ArchitectEngine::destroyAll() + 76

    frame #17: 0x00000001006d7860 ARExperience`wikitude::sdk_core::impl::ArchitectEngine::~ArchitectEngine() + 88

    frame #18: 0x00000001006d79e4 ARExperience`wikitude::sdk_core::impl::ArchitectEngine::~ArchitectEngine() + 12

    frame #19: 0x0000000100686ce8 ARExperience`wikitude::sdk_core::impl::Architect::~Architect() + 52

    frame #20: 0x00000001002935d0 ARExperience`-[WTARchitectManager dealloc] + 212

    frame #21: 0x00000001002ccbf0 ARExperience`-[WTArchitectView .cxx_destruct] + 56

    frame #22: 0x000000018bf82f10 libobjc.A.dylib`object_cxxDestructFromClass(objc_object*, objc_class*) + 148

    frame #23: 0x000000018bf8f6e0 libobjc.A.dylib`objc_destructInstance + 92

    frame #24: 0x000000018bf8f744 libobjc.A.dylib`object_dispose + 28

    frame #25: 0x0000000193742ddc UIKit`-[UIResponder dealloc] + 156

    frame #26: 0x00000001933a2e28 UIKit`-[UIView dealloc] + 1676

    frame #27: 0x00000001002cb458 ARExperience`-[WTArchitectView dealloc] + 136

    frame #28: 0x000000018d539e30 CoreFoundation`common_removeAllObjects + 188

    frame #29: 0x000000018d42bc70 CoreFoundation`-[__NSArrayM dealloc] + 28

    frame #30: 0x000000018bf9dfe0 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 704

    frame #31: 0x00000001933a2e08 UIKit`-[UIView dealloc] + 1644

    frame #32: 0x000000018bf9dfe0 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 704

    frame #33: 0x000000018d423db8 CoreFoundation`_CFAutoreleasePoolPop + 28

    frame #34: 0x000000018d4f5b20 CoreFoundation`__CFRunLoopRun + 1668

    frame #35: 0x000000018d424048 CoreFoundation`CFRunLoopRunSpecific + 444

    frame #36: 0x000000018eeaa198 GraphicsServices`GSEventRunModal + 180

    frame #37: 0x00000001934102fc UIKit`-[UIApplication _run] + 684

    frame #38: 0x000000019340b034 UIKit`UIApplicationMain + 208

    frame #39: 0x00000001000d5cfc ARDemo`main + 140 at AppDelegate.swift:14

    frame #40: 0x000000018c4085b8 libdyld.dylib`start + 4


full thread dump is attached. Will update this question if I can determine it's my code but any insights from the Wikitude side would be appreciated

txt
(21.3 KB)

Hi David,

We're currently investigating similar reports from other customers.

As our iOS example application also uses a UINavigationController, I would be interested if you can reproduce the same behaviour there as well?


I let you know once I have more information.


Best regards,

Andreas

Hi David,

We already fixed some instant tracking related issues. Here are some pre-release packages for iOS and Android. Please note that they only target specific instant tracking lifecycle related fixes, everything else might not behave as expected (Although I don't expect any issues).


Please let me know how it works for you


Best regards,

Andreas

Thanks Andreas, 


We will give this a try. To answer your earlier question no, I wasn't able to replicate it in the SDKExamples for 6.1. 


-Dave

Ok here are my notes from playing with the pre-release SDK for a couple hours.


1) It feels more solid to me in my testing within the app.

2) I was able to cause the deadlock again but I had to work really hard to do it. This involved basically launching and stopping and restarting my instant tracking experience, in combination with presenting view controllers on top, as well as popping the AR View controller off the navigation controller (deallocating it) and pushing it back on again. I did this between 20 and 30 times before I was able to cause the deadlock ... which subjectively is a lot harder than I have to work to cause it under stock 6.1


I did all this while attached to Xcode, here are two full thread dumps for the two times I was able to cause it.

txt
txt

Hi David,

Thx for all the tests you did! Both logs point to the same problem. We will investigate this one and send you another release asap.


Best regards,

Andreas

Thanks Andreas! Have you guys had success replicating this issue internally ?

Hi David,

Yes, with some minimalistic code changes internally, we're able to reproduce it all the time. I guess I can send you something soon ;)


Best regards,

Andreas

Hi David,

Here are the download links for iOS and Android.

The 'scanning a white wall' issue will be fixed soon as well.


Best regards,

Andreas

Hi Andreas,


We're trying out the new iOS build now. I haven't caused a deadlock yet (after maybe 5 entries and exits into the AR) however I did just crash during AR playback with a stack trace I haven't seen before:


* thread #42, queue = 'com.wikitude.sdk.render_queue', stop reason = EXC_BAD_ACCESS (code=1, address=0x40ffffffff0000b2)

  * frame #0: 0x0000000191ae5fe4 CoreVideo`CVBufferBacking::retainUsage() + 28

    frame #1: 0x0000000191ae6510 CoreVideo`CVOpenGLESTexture::initWithTextureBacking(CVOpenGLESTextureBacking*) + 84

    frame #2: 0x0000000191aeef00 CoreVideo`CVOpenGLESTextureCache::createTextureFromImageWithParams(__CFAllocator const*, CVImageBuffer*, unsigned int, int, int, int, unsigned int, unsigned int, unsigned long, int*) + 316

    frame #3: 0x0000000191aefa88 CoreVideo`CVOpenGLESTextureCacheCreateTextureFromImage + 212

    frame #4: 0x00000001002749b8 ARExperience`-[WTVideoDrawable presentNextPixelBuffer:] + 204

    frame #5: 0x0000000100273bc8 ARExperience`-[WTVideoDrawable updateNextVideoFrameAtTime:presentationDuration:] + 348

    frame #6: 0x000000010029f000 ARExperience`__94-[WTVideoDrawableManager updateVideoDrawablesForNextFrameAtTime:expectedPresentationDuration:]_block_invoke + 180

    frame #7: 0x000000010029f15c ARExperience`-[WTVideoDrawableManager enumerateVideoDrawablesUsingBlock:] + 232

    frame #8: 0x000000010029ef1c ARExperience`-[WTVideoDrawableManager updateVideoDrawablesForNextFrameAtTime:expectedPresentationDuration:] + 100

    frame #9: 0x00000001002701e8 ARExperience`-[WTARchitectManager renderService:willRenderNewFrameAtTime:withDuration:] + 92

    frame #10: 0x000000010026913c ARExperience`-[WTRenderPlatformService renderer:willRenderNewFrameAtTime:withDuration:] + 76

    frame #11: 0x00000001006c472c ARExperience`-[WTRenderer driver:willRenderNewFrameAtTime:withDuration:] + 76

    frame #12: 0x00000001006bd7cc ARExperience`__34-[WTGCDDriver triggerRenderFrame:]_block_invoke + 204

    frame #13: 0x0000000101d8525c libdispatch.dylib`_dispatch_call_block_and_release + 24

    frame #14: 0x0000000101d8521c libdispatch.dylib`_dispatch_client_callout + 16

    frame #15: 0x0000000101d9280c libdispatch.dylib`_dispatch_queue_serial_drain + 296

    frame #16: 0x0000000101d88ce4 libdispatch.dylib`_dispatch_queue_invoke + 672

    frame #17: 0x0000000101d94e6c libdispatch.dylib`_dispatch_root_queue_drain + 584

    frame #18: 0x0000000101d94bb8 libdispatch.dylib`_dispatch_worker_thread3 + 140

    frame #19: 0x000000018e5562b8 libsystem_pthread.dylib`_pthread_wqthread + 1288

    frame #20: 0x000000018e555da4 libsystem_pthread.dylib`start_wqthread + 4


I've attached the full thread dump as well.


Thanks

-Dave

txt

Ok one more crash with the latest pre-release sdk, still no deadlock though. This was on run maybe 18 of running the ar experience, leaving it (by pressing close on the nav controller its nested in) and running it again:


Xcode console message:


*** error for object 0x175063701: pointer being freed was not allocated


Thread that crashed:


image




txt

Hi David,

Thx for the feedback!

When are you calling the `-stop` method of the WTArchitectView? Did you manage to reproduce this crash more often?


Best regards,

Andreas

Marking as solved with the build pre-released here: https://support.wikitude.com/support/discussions/topics/5000082421

Login or Signup to post a comment