Log in or register to post comments

Unity iOS Integration Bad Access Crash

April 20, 2018 - 12:00pm #1

I'm currently attempting to integrate an xcode project exported from Unity that uses Vuforia, and I am running into some hard to debug crashes during Vuforia initialization. Using Unity version 2017.3.1p4.

I've been following a number of (admittedly somewhat outdated) guides on the subject, such as can be found at the links below:



These links direct you to copy the Classes, Libraries, and Data folders over, and modify header and library search paths to include them. They also instruct you to copy over relevant build settings such as linker flags and a few custom build settings that Unity adds in.

They then instruct you to do a kind of integration with the unity application delegate, overriding it with your own delegate and passing through the relevant  callbacks (didFinishLaunchingWithOptions, didBecomeActive, etc). I've done that, and I have proven that this step works at least conceptually by taking the exported build and creating an alternative application delegate inside of it with a simple view controller with a button that launches and displays the Unity content. This standalone build works, and is able to initialize Vuforia just fine.

I've completed all of these steps with my existing project, and it completes the build phase and deploys to my test device just fine. However, when I go to run my application, and I trigger the unity window to run, i get a crash just after "Initializing Vuforia..." is printed to the debug log. The exception occurring is an EXC_BAD_ACCESS inside Vuforia::init after it's called from initQCARiOS (don't have the source since the method's inside a static library, so I can't say what exactly it's doing in there). Unfortunately the stack trace consists of processor instructions at this level, so there isn't a lot to go on. Does anyone have any information on why this might be occurring? I figured that usually an EXC_BAD_ACCESS would happen when something got deallocated and then referenced again, but turning on zombies doesn't print any extra information (though this may also be because we're dealing with non-objective-c code as well, I don't fully understand how NSZombie works). I have a couple of thoughts about what might be happening:

1. It's possible that some asset is being left behind when I'm copying resources over, and Vuforia, upon attempting to access that asset, is accessing an invalid memory location. I don't, for example, copy any of the xcassets over because they just contain the launch and app icon images, but I can't imagine why Vuforia would be accessing those. I do copy everything from Data, and add the Vuforia folder in Data/Raw as a referenced folder as well (mirroring how it is setup in the exported project). I also have added the MapFileParser script to my build phases, which appears to use the MapFileParser to do something to the data assets after the build is mostly finished, though I'm really not sure what.

2. It's possible that I've missed a build setting somewhere. My builds themselves aren't failing, which would make this a bit hard to track down, but the build settings aren't something I auto-copied over, I manually looked at all of the customized build settings for the exported app and updated my existing settings as necessary.

3. It's possible that something my app is doing in between launch and me pressing the button is interfering with something Vuforia is trying to access. I find this one the least likely. While the app I'm integrating with is fairly large and somewhat complex, ultimately it isn't doing anything that would affect things like rendering devices nor is it fiddling with low-level graphics objects. And my approach to integration when it comes to modifying the app code is proven sound with the same modifications being done to the exported Unity build, and it working just fine.

So that's where I am currently. Any information about what exactly goes on in the Vuforia initialization process would probably be of great help, as I could at least narrow down some potential problems. Additionally, any tips about tricky build settings or assets that might not look required but need to be a certain way would be helpful. I know that this isn't the ideal way to do this, usually if you would be looking to integrate with an existing iOS app you'd build natively on iOS, but these were the requirements I was given unfortunately. I would appreciate any pointers that anyone could provide!

Unity iOS Integration Bad Access Crash

April 30, 2018 - 2:33pm #3

Thank you for the reply! Our plist file does have a description of why the camera access is needed, and if Vuforia initialization is delayed, we do see the camera permission dialogue. Only when the Vuforia init method is called is when we're seeing this. We have also tried the using version of Vuforia with Unity 2018.1, to no avail. From what I can tell, there must be something that explicitly ties the exported Vuforia library to whatever project it was exported into from Unity, and this bad access crash occurs specifically during a strcpy operation being called from somewhere down the call stack from that method.

Many people have pointed towards the plist file as a potential reason. While we do have all of the relevant permissions descriptions accounted for, is there any hard dependency on this file in the Vuforia library? Any issue with the name or physical location of the plist in the project, or order of the property entries, the changing of which might account for this?

Unity iOS Integration Bad Access Crash

April 23, 2018 - 7:33am #2


Some thoughts/questions:

  1. When running the app, are you seeing the camera permission dialogue?
  2. Does your plist file have a description of why camera access is needed? If there was an issue related to these we would expect a log line mentioning that it is missing.
  3. Have you tried using SDK 7.1 as packaged with Unity 2018.1?

If you are able to share the log, crash dump file and perhaps even the project we may be able to take a look. Feel free to DM me if these are too sensitive to post to the forums.


Vuforia Support

Log in or register to post comments