Start a new topic

Frequent crashes in AR

Frequent crashes in AR


In our app, we are showing 30 POIs, each with its own background image. The app functionality is such that the AR view is the central view and its possible to frequently switch b/w AR and other views. After creating new POIs again, the app comes back to AR. After doing this a few times, the app crashes. Most times the "Wikitude SDK: Texture memory exceeded" warning is shown. Even otherwise the app crashes with following error:

* thread #62: tid = 0x28a8e, 0x002ef9a8 AppName`Core3D::Renderable2d::draw(Core3D::RenderableInstance&, PVRTMat4 const&) + 52, queue = 'com.wikitude.architect.renderqueue', stop reason = EXC_BAD_ACCESS (code=1, address=0xe1c39fd3)

  * frame #0: 0x002ef9a8 AppName`Core3D::Renderable2d::draw(Core3D::RenderableInstance&, PVRTMat4 const&) + 52

    frame #1: 0x002ae904 AppName`Core3D::BillboardManager::draw(PVRTMat4 const&, bool, float) + 160

    frame #2: 0x002af3ac AppName`Core3D::Core3DEngine::render() + 332

    frame #3: 0x002af11a AppName`Core3D::Core3DEngine::renderScene() + 338

    frame #4: 0x00278aba AppName`ArchitectEngine::architectLoop() + 378

    frame #5: 0x005b780e AppName`gameplay::Game::frame() + 342

    frame #6: 0x00258ca0 AppName`__34-_block_invoke + 776

    frame #7: 0x3af51d52 libdispatch.dylib`_dispatch_call_block_and_release + 10

    frame #8: 0x3af56cbc libdispatch.dylib`_dispatch_queue_drain + 488

    frame #9: 0x3af53c6e libdispatch.dylib`_dispatch_queue_invoke + 42

    frame #10: 0x3af575f0 libdispatch.dylib`_dispatch_root_queue_drain + 76

    frame #11: 0x3af578dc libdispatch.dylib`_dispatch_worker_thread2 + 56

    frame #12: 0x3b082c16 libsystem_pthread.dylib`_pthread_wqthread + 298

    frame #13: 0x3b082adc libsystem_pthread.dylib`start_wqthread + 8

 

Also when the POIs are being loaded, the following logs can be seen:

Wikitude SDK: GeoObjectInterface::setRadarDrawables: Unknown drawable (21)

Wikitude SDK: Image (0) not found.

Wikitude SDK: GeoObjectInterface::setRadarDrawables: Unknown drawable (32)

Wikitude SDK: Image (0) not found.

and so on. The images are only of 100x100 resolution. Neither did reducing the number from 30 to 20 nor reducing image size to half the current size helped. Also, I am creating only one AR.ImageResource instance for each POI and am clearing the architectview cache and also destroying all the data in AR view, each time the view appears. Still the app does not stand up for too long. Thanks in advance.

Hi,

can you tell us more about your environment, which will help us isolate the issue.
Device
OS version
SDK version
Extensions or plugins (PhoneGap, Titanium) and their version.

 

As for device and OS, its happening in all of them. OS 6.0 to the 7.1 and all devices, even in 5S. I am using the latest SDK - 3.3.1. Not using any extensions or plugins.

Hi,
Seems that you are running into multiple issues at the same time. So let my clarify some logs and explain to you how you can use the Wikitdue SDK more efficiently.

Wikitude SDK: Texture memory exceeded:
This log is printed each time you want to load an AR.ImageResource that can not be loaded into the texture memory. This does not result in a crash. You simply see a black texture instead of the original image.

Crash in RenderableInstance:
Right now I'm not sure whats the reason for this crash. It would be very helpful if you could send us a demo project with which we can reproduce the error.

Additional Wikitude SDK logs:
Those 'unknown drawable' or 'not found' logs appear each time you want to use/modify a JS object which does no longer has a counterpart in C++. So the object was destroyed in C++ but not in JS. 

 

What you should try:
As far as I understood, you're loading the ARchitect World each time the Wikitude SDK view comes visible. You don't need to do this. You can load the ARchitect World once and then simply use the '-start / -stop' methods (ObjC SDK) to pause and resume the rendering when switching between other views. The ARchitect World will resume exactly where it was paused.
The -clearCache method does only affect the web view cache and not the SDK cache (3d models, tracker, images, sounds). As far as you dont want to load differnt content, you also don't need to call the destroyAll() function in JS.


I hope this answer was usefull. Please also watch for developer channel releases which we will publich each two weeks. They include the latest bug fixes and improvements from the last development sprint.

Best regards

Andreas

@Andreas I have emailed the project code to you, please look. Also, the app is crashing more frequently in iPhone 5c. Especially while switching b/w apps and while returning back to the app from lock screen. The lock screen issue is happening on all devices at times.

* thread #67: tid = 0x7efd, 0x0035cc22 Taggifi`Core3D::Program::updateAlphaValue(float) + 2, queue = 'com.wikitude.architect.renderqueue', stop reason = EXC_BAD_ACCESS (code=1, address=0x4)

  * frame #0: 0x0035cc22 Taggifi`Core3D::Program::updateAlphaValue(float) + 2

    frame #1: 0x0039d772 Taggifi`Core3D::Renderable2d::draw(Core3D::RenderableInstance&, PVRTMat4 const&) + 86

    frame #2: 0x0035a3ce Taggifi`Core3D::BillboardManager::draw(PVRTMat4 const&, bool, float) + 154

    frame #3: 0x0035ae5c Taggifi`Core3D::Core3DEngine::render() + 332

    frame #4: 0x0035abd6 Taggifi`Core3D::Core3DEngine::renderScene() + 338

    frame #5: 0x00322214 Taggifi`ArchitectEngine::architectLoop() + 392

    frame #6: 0x0062f574 Taggifi`gameplay::Game::frame() + 260

    frame #7: 0x00302f84 Taggifi`__34-_block_invoke + 588

    frame #8: 0x39656d52 libdispatch.dylib`_dispatch_call_block_and_release + 10

    frame #9: 0x3965bcbc libdispatch.dylib`_dispatch_queue_drain + 488

    frame #10: 0x39658c6e libdispatch.dylib`_dispatch_queue_invoke + 42

    frame #11: 0x3965c5f0 libdispatch.dylib`_dispatch_root_queue_drain + 76

    frame #12: 0x3965c8dc libdispatch.dylib`_dispatch_worker_thread2 + 56

    frame #13: 0x39787c16 libsystem_pthread.dylib`_pthread_wqthread + 298

    frame #14: 0x39787adc libsystem_pthread.dylib`start_wqthread + 8
Login or Signup to post a comment