I have an external static library (I have the source code as well) that uses 'fopen' to access files on the filesystem. The strange thing is that it always fails both on simulator and device when it tries to do so with EXE_BAD_ACCESS inside fopen$UNIX2003 (not in fopen, fopen is not even in the call stack when the exception is thrown. I've tried to use fopen directly myself with the same path/options and it works. So, first of all, is it possible that the library is somehow calling a different fopen implementation? If so, why, and most important how can I make it call the 'right' one?
EDIT: Actually, the last function in the call stack before the exception is thrown is _interposition_vtable_unimplemented, fopen$UNIX2003 precedes it.
fopen$UNIX2003 is a symbol that is provided by OS X and is not part of the iOS Simulator runtime. iOS is always conformant and thus does not have legacy (non $UNIX2003) variants of functions (which are provided for binary compatibility with code built against older versions of the OS X SDK).
The common cause of the issue you are seeing is that you have an object file or archive (libsomething.a) that was built against the OS X SDK and are trying to link it into your iOS Simulator executable. That is not supported as the two platforms are not binary compatible at that layer.
You need to rebuild your library (the libsomething.a) against the iOS Simulator SDK.
This problem results in an abort at runtime on iOS 7 but is now a link error at build time on iOS 8, and that seems to have helped make these issues much more obvious.
Related
I have a "fat" framework built for iOS, which is being used in a debugging tool built for macOS. Previously I was linking this framework statically, which worked, even though XCode complains about it being built for the simulator (since the architecture is the same). But now, newer versions of the library are dynamic, so that route doesn't work, as the tool is a command line application, which doesn't support embedding frameworks.
I could turn it into an application bundle, it seems, in order to solve that, but I'm not sure what this entails (creating a new project?). I can certainly figure it out but ..
In the meantime, I thought I'd load the library dynamically using dlopen() etc and retrieve the classes/methods I need (I already have some code for this which at least compiles). However, that call fails with the following message:
no suitable image found. Did find:
/<path to library file>: mach-o, but built for simulator (not macOS)
Since linking statically is only a warning and actually works, is there a way to make dlopen work as well?
Recompiling the framework itself is not an option for me in this situation.
Are you considering editing the binary of the dylib framework? If so in the Macho-O header you could try changing LC_VERSION_MIN_IPHONEOS to LC_VERSION_MIN_MACOSX.Probably it won't be enough,but it's a simple change for a quick test. Here's a screenshot comparison of those load commands in MachOView
Also covered the other way round here
I've been running a Xcode project on my iPhone but I haven't upload the binary yet. The thing is that I've lost the code on my Mac (that's what happens when you don't commit con GitHub) and the only thing I still have from the project code is the "app" that the iPhone saved when I run it for the first time. Is there any way to pass the code from the iPhone or see the code?
No. Your code was compiled, linked and packaged to produce the application, and it is the resulting compiled binary that has been installed on your phone.
You may be able to retrieve resources (storyboards, XIBs, images, plists...). For the code, there may be decompilers (not sure if there are any for Objective-C or Swift, though), but they will not reproduce your original code, just code that compiles to the same thing (i.e. without comments, with arbitrary names for local and instance variables, etc.).
Don't you have a Time Machine backup of your project?
I have an Adobe Air application that I am packaging for iOS.
If the target is ipa-debug-interpreter or ipa-test-interpreter the app works just fine. However, any other target it crashes when trying to use assets. I have seen the following exception:
[Fault] exception, information=ReferenceError: Error #1065: Variable FlexVersion is not defined.
Fault, SpriteAsset() at SpriteAsset.as:131
131 if (appDomain.hasDefinition("mx.core::FlexVersion"))
Other times it will crash with no stack.
Why would it only work when the target includes interpreter?
Packaging with interpreter is faster than the regular debug packaging (not that I've ever noticed a timetable difference). I would hazard a guess that for it to be faster it must bypass certain processes which the normal debug would check for. From the type of error you're getting I would suggest you double check your manifest XML file for missing packages and/or the version of the AIR SDK you are targeting. Hope this provides some help.
EDIT: May also be worth revision which version of the FLEX SDK you are targeting and this can cause issues of this kind.
I have been given a Shared Object file (.so) and the functions inside of it, but I don't have a clue as to how to use it, or alter it for use in an iOS application. Could someone point me in the right direction?
I know the .so came from an Android application, but I was told I could get it to work in an iOS application as well.
Actually and technically, yes, you can, but not in a way you would ever think.
If it came from Android, it is probably compiled for ARM. So it should be binary-compatible with the ARM CPU in iOS devices. However, iOS doesn't use the usual format of shared objects (that is, the ELF format), but iOS' and OS X's own Mach-O format.
This means that you cannot directly link against this shared object file nor are you able pass it directly to dlopen() and dlsym(). You have to get into serious hacking (something that you probably don't know). This involves loading and relocating the file properly.
An example of this can be found in iOS jailbreak developer and hacker, Comex's GitHub repository Frash, a Flash player for jailbroken iOS devices. Comex essentially wrote an ELF loader module (dubbed "food") for iOS and used it to make Android's libflashplayer.so work on iOS. Pretty neat, huh?
Also note that this is not going to be possible for AppStore apps as it needs dynamic loading and various alterations in the OS.
while technically possible (see h2co3's answer) for anything practical the answer is no
so files arent in the correct binary format
even if they were, dynamic loading is not allowed by appstore
I'm working with a static framework I've created (built with the help of Karl Stenerud's iOS-Universal-Framework toolchain), which I intend to distribute. A static framework's a bit more convenient than simply using a static lib + headers - I like the ability to just drop a framework in and begin using it immediately, instead of needing to do things like set up appropriate header search paths.
However, I'm seeing some downright bizarre behaviour. Several test/sample apps that I have built with the framework are crashing with either "Bad system call: 12" or "Job appears to have crashed: Illegal instruction: 4" when run on iOS devices to which the app has been deployed via an ipa.
The code itself is fine. The crash does not occur when a static library is used instead of a framework. It also doesn't crash if the app is deployed via the debugger in Xcode, even when the Release build configuration is used.
The crash only happens when deployed via an ipa, and when the library is linked as a static framework.
Interestingly, the corresponding crash log's stack trace entries leading up to the crash (which is EXC_CRASH or EXC_BAD_INSTRUCTION) cannot be symbolicated.
In one instance, I was able to track the crash down to the point where a static C function is called. By removing the "static" keyword on a whim, I was able to stop the crash happening.
Unfortunately, this doesn't appear to be the silver bullet - I'm also seeing a crash on a non-static C function call.
But in all cases, the crash occurs when a C function is being called.
So, my question is this: Has anyone else seen this before? Any theories? Is this likely to be an LLVM bug? Some magical compiler/linker flag I'm missing? Have Apple deliberately only half-supported static frameworks because there are issues? Do I just need to abandon my plan to distribute a framework, instead of a static library and assorted detritus?
Many thanks in advance,
Michael
The problem would appear to be related to static recursive functions!
Quoting Karl Stenerud, who figured it out:
It fails if you have a static recursive function:
#implementation Fibonacci
static int internalFibonacci(int value)
{
if(value <= 1)
{
return value;
}
return internalFibonacci(value - 1) + internalFibonacci(value - 2);
}
+ (int) fibonacci:(int) value
{
return internalFibonacci(value);
}
#end
If you call [Fibonacci fibonacci:] it will fail with "Bad system call: 12".
If you remove "static" from internalFibonacci(), it works perfectly.
I already came across similar issues. I develop iOS frameworks for a company and we provide those framework to clients who develop their own applications or framework above ours.
When we perform testing in our own, everything seems to work fine and applications just work perfectly. But as soon as applications/frameworks are built using different Xcode/Compiler version, there is no guarantee that everything will work just as expected.
The crashes that clients reported to us do always mention a bad code execution or bad arm instruction (the same as you got).
We searched a lot around the Apple developer forums but there few mentions to this issue, and Apple doesn't really seem to want to communicate about that.
From my experience, here are some clues that may perhaps help you:
Build your framework on Xcode 4.1, iOS SDK 4.3 and Apple LLVM 2.1
on OS X Lion, Xcode 4.3 you can build using LLVM GCC and make sure to disable THUMB support in your build settings.
You can try the last solution. I have made many tests with all possible compilers on OS X Lion, and so far, this configuration appears to be stable.
I haven't tested yet the new Xcode 4.3.2 and iOS SDK 5.1. I'll let you know as soon as I do it.
Regards,
Hichem