Starting with 5.0.3p1 (today), 4.6.6p2, and 5.1.0p1 (both yet to be released), we have improved managed stack traces reported by IL2CPP. They should be correct now in a all cases, so if you see a problem, please let us know, as it might be a bug.
We’re creating better managed stack traces by parsing the linker map file and generating a binary file with information about method sizes and offsets that we ship with the application. You’ll see a native executable named MapFileParser in the Unity editor build directory for your project. We use a Run Shell Script build phase in Xcode to run this utility and generate the data we need at runtime.
We know that some customers use a build configuration where the Unity Editor on Windows generates an Xcode project that is then copied to an OSX machine to actually build for the device. In this case, the MapFileParser utility won’t get into the Xcode project correctly, and the runtime will fall back to the previous stack trace code (which is sometimes incorrect). You should see a message in the Xcode build output indicating that the linker map file could not be used if this happens.
I’m interested to know how many users are using this Windows → OSX build process for iOS builds. For those that do use it, do you have a Unity installation on the OSX machine? This will help us determine how to better support this build configuration. Thanks!
We use the Windows → OSX build process you describe. We do not use Unity on the OSX machine at all.
I tried 5.0.3p1 and tried to publish our project with IL2CPP from windows, but got a failure error that it couldn’t find a MapFilterParser executable “C:\Program Files\Unity503p1\Editor\Data\Tools\MapFileParser\MapFileParser”. When I went to the “C:\Program Files\Unity503p1\Editor\Data\Tools\MapFileParser” directory, I saw a MapFileParser.exe file in there, but no MapFileParser file. So I made a copy of the MapFileParser.exe called MapFileParser (without extension) in that directory and the publish worked.
However, once I tried to build inside of XCode, I got yet another error that “MapFileParser” wasn’t a valid executable. This makes sense, since it’s trying to execute a windows binary on OS X. To fix this, I replaced the MapFileParser file with a shell script that does nothing.
That worked.
Long story short, I don’t think the fallback logic you describe is working correctly right now, because Unity is still trying to do stuff with the MapFileParser exe when the project is published from Windows – Both on the Unity side and the XCode side.
I’m glad I was able to work around it for now, since we’ve already been waiting on this latest patch to fix another critical ByteCodeStripper error that was preventing us from publishing using IL2CPP for the last couple of months.
Thanks for letting me know. Can you send me the full Xcode log from the project when the error happens in Xcode due to a missing MapFileParser executable? We should be able to correct both issues for the next patch release.
Another work around is to copy the MapFileParser utility from an OSX editor installation into that directory (Editor\Data\Tools\MapFileParser) in the Windows editor installation. Meanwhile, we have a fix for this bug that should make it into the next patch release.
Hello. I just stumbled upon the same problem with MapFileParser on 5.1.0p on Windows 8.1 (I like to build from windows to a remote location and then run on iOS from X-Code). I am going to try to apply the above workaround for now.
I am working only on OSX for both the creation of the xcode project and app/ipa. I am running 4.6.6p3 and the file is present in my build output, but I don’t think it’s valid. I get a Permission Denied error:
…/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/Unity-iPhone.build/Script-033966F41B18B03000ECD701.sh: line 12: …/MapFileParser: Permission denied and it fails my build.
I trimmed the paths down a bit to remove my environment specific information. Is this a known issue? I am building using batch mode.
This is not a know issue. Maybe the MapFileParser is ending up with the wrong permissions after it is copied into the output directory. Can you take a look to see if it has the execute permission? If not we may have a bug where we need to set it correctly.
I cannot reproduce it all the time. Mostly speaking it works fine. I’ve noticed that once due to my previous VB problem: it shows that some code in Standard Assets (shall be Effects right?) wronged but I have never referenced to it.
Thanks, let me know if you find something that happens at least somewhat regularly. I suspect the issues is related to how the linker lays out the native code in the binary, so it may be difficult to reproduce in many cases.
Click the Stop button, change drop down to point to the iPhone 5 and running it, the XCode console displays this: *** loading to inventory: LXMXFCgLAlggQGMId210MhQDKB0FVCcHKht/Gi1zDxA3HUkNbCU2VSFjenMFFCkbGV4+FjBWK2Nsc0NdeBEfUiMrPRt/YzE+DRUFGx5FPAc3WjxjenMCHTsL
Is the iPhone 5 a 32-bit device (i.e. and iPhone 5 or 5c, not a 5s)? If so, that might explain the difference. This really looks like something we should investigate here. Can you file a bug report?
I think that this should be possible, but it is not something we’ve implemented yet for IL2CPP. Since the behavior differs from Mono, I would classify this as a bug. Can you submit a bug report? We an look at implementing it then. Thanks!