Assertion at aot-runtime.c:2729, condition `plt_entry' not met

Morning all,

I'm getting a crash on older devices

ios Assertion at aot-runtime.c:2729, condition `plt_entry' not met

and i'm not at all sure why this is happening. I don't think i'm running out of memory but i could be wrong. Basically it loads up the launch screen and thats it... crashes out to the springboard from there. I'm not seeing this on NEWER devices so i'm at a bit of a loss. I think i remember older builds giving me a memory error when it would crash out if it was memory related.

Cheers
Bryan

 

some notes to add... it doesn't look like i'm running outta memory or dealing w/the normal time issue problems on normal devices. Running the profiler i see that memory wise i only hit 2.5 megs, so its not even loading much of anything at that point and time wise we die under 10 seconds. ITs annoying because i really get NO error messages, just the above message.

 

We got this too.

We were linking a third party "thumb" library to the project, and that makes the ARMv6 binary crash.

 

Me too...

Debug log bellow.

Is it a bug or am I doing something wrong?

I'm using sdk 4.3, target ios 4.2 and integrating Openfeint 2.10.1 and 2 Prime31's plugins (Mobclix and StoreKit).

 

It seems the problem is related to iOS SDK 4.3 not supporting armv6-only builds. Try building for universal / standard (armv6 + armv7), or downgrading your development environment to sdk 4.2 + xcode 3.2.5.

 

Downgrading is the way to go:

http://forum.unity3d.com/threads/83076-iOS-4.3-App-Rejected

At least for a while...

 

Hi Immersiva, it seems that we will set the Target Platform to arm6 in Unity to generate the xcode project and then to change the building for standard (armv6 armv7) in order to get it run on older devices( 2G touch runnning 4.2.1)?

And I also found that add -ObjC linker flags will cause assertion fail with older devices? I've trying to OpenFeint Unity Plugin.

 

I've narrowed this down (at least on our end) to being a flurry issue. Essentially the flurry files will build but i get this error when running on older platforms. I'm NOT setting it to just arm 6 and i'm also using the older xcode. Any one have any issues at this level?

 

Hey Guys,

We are having a similar issue (I just posted to the unity answers site too, hopefully this isnt too spammy)

Anyhow, here is the strangeness:

We had an app that took a long time to load on older hardware, but worked fine on all our test devices. However, once in the wild, for some reason the first scene was taking too long to load and on the 3G it was getting jettisoned for load time.

I added a stub scene at the front, I built it for AdHoc, and installed it on an old 3G. It runs fine, if a bit slowly.

It runs fine on all newer devices.

We submit to apple, it gets approved.

on the same 3G that ran the AdHoc just fine, I install the app from the app store and it shows the splash screen, and crashes right before the first scene is loaded. (ie it takes about 7 seconds to load the first scene on the adHoc build, this is a very small stub scene, and it takes about 7 seconds to crash on the app store version)

In the device console I can see that it is launching and starting to load Unity because I get a handful of 'this message is harmless' type logs and then the crash line:

<Notice>: Non platform assembly: data-0x4022000 (this message is harmless)
<Notice>: Non platform assembly: data-0x13fe600 (this message is harmless)
<Notice>: * Assertion at aot-runtime.c:1734, condition `!is_wrapper' not met

This bug is not re-creatable in the dev environment (as far as I can tell, since our stuff works just fine as an adHoc) I dont know how to simulate a distributed app.

Any info from anyone would be much appreciated.

Cheers!
-Ben

 

Hey I got this error due to a flurry plugin, dont know it it helps

 

Thanks Oliver, we are using flurry, and it is a slightly outdated version of their API. I guess I will just update it and resubmit and hope for the best!

 

Well let me know, I had to change to localytics. I even contacted flurry support and prime31 who created the plugin.

 

I also had the same problem with the plugin for Prime31 using the Flurry. I decided to test on another Mac with XCode 4.2 with iOS 5.0 (the other was an XCode 4.0.2) and I have not had this problem.

For people who are using Flurry: look at the FAQ part of the Flurry.
Q: What version of XCode is required?
A: Going forward, the Flurry SDK will only support Xcode 3.2.5 and above. Please email support if you need to use older versions of the Flurry SDK. This version of the Flurry SDK is compatible with Xcode 3.2.5 and designed for OS 4.3 (iOS) applications.

 

Ah yes... unfortunatly arm6 devices are stuck on something like IOS 4.1.

 

Was anyone able to solve this using the latest XCode and SDK?

 

Any solution for this problem?

 

Had the same problem. I disabled Script Debugging and Development build on my Build Settings. Worked after that. Weird, no?


.. and just to verify, I re-enabled said options, and the same error returned xD

 

Had the same problem. I disabled Script Debugging and Development build on my Build Settings. Worked after that. Weird, no?


.. and just to verify, I re-enabled said options, and the same error returned xD

 

I'm getting the same error, and it appears to be all down to Openfeint in my case. I assembled the most basic Openfeint project (the demo one that comes with the Openfeint Unity download), works fine on iPad 1, 2, and iPhone 4, iPhone 4S. Anythgn else, I get that error...

condition `plt_entry' not met

Xcode Version 4.2
Unity version 3.4.2
Openfeint version 2.1.17

Really important I get this workign (or at least confirm that it definately never will be able to)

 

Chiming in, since I've also had the same problem.

From my findings so far, I was able to use the Flurry Analytics library in my project and run the game on armv6 devices ONLY because I set the stripping level to "Strip bytecode" or "Use micro mscorlib" and I set Target Platform to "armv6 (OpenGL ES1.1)".

It looks like that those with only the Unity iOS Basic license won't be able to get their games to run on armv6 unless they remove Flurry Analytics from them. Unfortunately, being able to have Flurry Analytics in their games is a huge deal to many developers.

 

For any folks using our plugin it is fully ARM6 compatible as of a couple months ago.

 

I'm suddenly seeing this after adding the Prime31 Social Networking plugin to my project. I followed suggestions above and my project settings are armv6 and stripping level set to "Strip ByteCode". I tried setting stripping level to "Use micro mscorlib" but that causes the bytecode stripper to crash, claiming it couldn't find a file, so that didn't even get me a usable project. Now, I don't get the aot-runtime assertion, instead I get

Using monoOptions --debugger-agent=transport=dt_socket,embedding=1,defer=y,address=0.0.0.0:56973
Symbol file /private/var/mobile/Applications/70A2A00A-8BA0-4D2C-8AB6-5B33D78306CA/glitchamaphone.app/Data/Managed/mscorlib.dll.mdb doesn't match image /private/var/mobile/Applications/70A2A00A-8BA0-4D2C-8AB6-5B33D78306CA/glitchamaphone.app/Data/Managed/mscorlib.dll
Symbol file /private/var/mobile/Applications/70A2A00A-8BA0-4D2C-8AB6-5B33D78306CA/glitchamaphone.app/Data/Managed/mscorlib.dll.mdb doesn't match image /private/var/mobile/Applications/70A2A00A-8BA0-4D2C-8AB6-5B33D78306CA/glitchamaphone.app/Data/Managed/mscorlib.dll
Symbol file /private/var/mobile/Applications/70A2A00A-8BA0-4D2C-8AB6-5B33D78306CA/glitchamaphone.app/Data/Managed/mscorlib.dll.mdb doesn't match image /private/var/mobile/Applications/70A2A00A-8BA0-4D2C-8AB6-5B33D78306CA/glitchamaphone.app/Data/Managed/mscorlib.dll

Seems like maybe it's just stale data that the project builder is not overwriting when it should be, but I dunno. I'm stumped for now and calling it a night.

 

You don't need to worry about ARMV6 in the future anymore.
iOS6 is completely removing any support for it and universal builds and I would assume that apple will reject any build including ARMV6 the day iOS6 is released. As you can update apps to no longer support it (just release the app built with min sdk 4.3+ - apple will accept it), you do not need to leave your customers behind.

What kind of AOT error do you get on the byte code stripping - does it work without any stripping?

 

If it helps anyone: I got the same error on unity 5.1.2 mono build for armv7 (I keep building on mono for testing because it's faster). It got fixed by deleting the Data folder and adding it back into xCode project DIRECTORY (not in the project itself) from the new Unity build. The cause was setting the stripping level to mscorlib (and then switching back and forth but the error remained).