I downloaded this project to give it a try (http://www.hatzlaha.co.il/150842/Lucas-Kanade-Detection-for-the-iPhone). It also has a released version on AppStore.
When I downloaded the source and compiled, it gave compilation errors. I changed the compiler to LLVM GCC and it instantly compiled without any errors or warnings.
Further here is what I did:
Downloaded the app Lucas Kanade on personal iPhone. Runs as expected (ie. shows tracked points and video output).
Deployed the above compiled app on company iPad. Here is shows the tracked points (which means the application is getting the video frames) but not able to display the video output.
General app flow:
Grab a frame from the camera.
Process the frame (track points).
Output the frame, so the screen looks like its showing the camera feed, as expected.
Device details:
iPhone: OS 5.1.1 (9B206); iPhone 4;
iPad: OS 5.1 (9B176); iPad 2;
Questions
Is the video output problem occurring because of the different in OS versions or because of the GCC compiler being used?
If it is the compiler problem, would be be appropriate to put the compile errors here for resolution or do I need to start a separate Question?
I know this info might not be enough since there are a lot of unknowns, but trust me, getting into the details of the app would be a really exhaustive problem description. Let me know what more info is needed to guess the solution. I'll update it here.
Like you already said the info is not enough. I can just guess. The projects for tracking points uses generally their own driver for camera access. The reason, why it does not work with llvm compiler, might be that.
Just look in the project if you find any file specific to iPhone. They are mostly dat files. And maybe you find some preprocessor macros in the project like #ifdef target_iphone something like that. In that case you can contact the producer and request the driver for iPad.
I did not download and tried the project, but it is just a guess.
Related
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?
As of yesterday, image files were being pulled from the image folder correctly to build character models, but now most of the calls to display.newImageRect result in a black rectangle. This glitch only occurs on iOS, not in Android or the Simulator. Any suggestions?
There have been no changes to the code involved with loading images.
Corona: v2014.2393
OSX: 10.9.5
XCode: 6.1
There are no messages in the console that would indicate being unable to load the images or anything of that nature, and the issue is that it works in the simulator, and on Android. However, when the application is built for iOS, the error occurs when building character models and loading most of the images, but, curiously, using the exact same module in another scene (a far less complicated scene) works still. Texture memory used stands around 15MB. I don't know, if that might be the cause of the error, but I'm fairly certain that it isn't. As I said, the curious thing is that a build from 2 days ago still works and loads the images just fine.
For clarity, all image files are PNGs.
UPDATE: The same bug occurs on earlier builds that previously functioned. So, this might be an issue with iOS or, at least, our app's compatibility with the latest version of iOS 8.
Using an older version of XCode and Corona seems to work only when building the older version of the application. Furthermore, purposely misspelling file names results in a different error. So, it's not that the images are not being found. Using the same image files in a working build on another machine doesn't produce the glitch either. Nor does transferring copying the modules for image loading over to the older build.
I'm seriously baffled.
If you can reliably reproduce this issue, I suggest you ask on Corona forums or report a bug with them.
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 need to debug the startup for an ios application on an actual device... and by start up I mean the very first instruction that is is executed when the OS hands control over to the app. Not "main". Also, this application doesn't have any symbols (ie. the debug information isn't available.. yet). I don't care if I have to debug at the CPU instruction level. I know how to do that (done it for over 30 years). I want the debugger to stop when control is about to transfer to the app. When I use the Attach|by Name command and run, it just says "Finished running".
Oh, and this application was not built in XCode. It is, however an application I built, signed and provisioned and moved to the device. The application does run since I can see the console output. Just in case you're thinking I'm some hacker trying to debug someone's application.
How's that for a tall order? I'll bet nobody can answer this... I've not been able to find any information on how I could do this with an XCode-built project. I wonder if it is simply not possible or "allowed" by the Apple overlords?
What do you say, Stack Overflow gods?
UPDATE: I should clarify something. This application is not built with any commercially available or open-source tool. I work with a tools vendor creating compilers, frameworks, and IDEs. IOW, you cannot get this tool... yet. In the process of bootstrapping a new tool chain, one regularly must resort to some very low-level raw debugging. Especially if there are bugs in the code generated by the tools.
I'm going to answer my own question because I think I've stumbled upon a solution. If anyone has anything more elegant and simple than this, please answer as well. On to the steps:
Starting with a raw monolithic iOS executable (not a bundled .app, but the actual binary mach-o file that is the machine code).
Create a new like-named empty Xcode project. Build and run it on the device.
Locate the output bundle's .app folder.
Copy the above raw iOS executable over the existing one in the .app bundle's folder.
The application will now have an invalid signature and cannot be deployed and run.
Run codesign against the app bundle (you can find out the command-line by running xcodebuild on the above Xcode project).
In the bundle's .app folder, run otool -h -l on the binary image. Locate the LC_UNIXTHREAD load command and find the value associated with the 'pc' register. This is address where the os loader will jump to your application. If this address is odd, then these are Thumb instructions otherwise it will be ARM (I think that's how it works).
Add a symbolic breakpoint (I used GDB instead of LLDB) and enter the address as '*0x00001234' as the symbol.
Select Product|Perform Action|Run Without Building.
Assuming that GDB is able to evaluate the breakpoint expression and set the break point, and you've selected Product|Debug Workflow|Show Disassembly When Debugging, the process should break at the very first instruction to be executed in the application.
You can now single step the instructions and use the GDB console to get/set register values.
Your question does not make sense - main is the entry point into the application. It is the first code that should be encountered, unless possibly you have initialize() overridden for some classes (but even then I think main would get hit before the runtime).
I think you are seeing some kind of odd error on launch and you think you want to set a breakpoint on entry to catch it, but far more likely what would help you is to describe the problem on launch and let one of the 4000 people who have seen and fixed the same crash help you...
However, if you really want to use GDB to break on an application with no symbols (but that you launch from XCode) you can have GDB break on an assembly address as per:
How to break on assembly instruction at a given address in gdb?
To find the address of main (or other methods) you can use tool or atos, some examples in this question:
Matching up offsets in iOS crash dump to disassembled binary
ADDITION:
If for some reason XCode cannot launch your application for debugging, you could also jailbreak and install GDB on the device itself which would give complete control over debugging. If XCode can launch you application I see no reason why being able to break at an arbitrary memory address does not give you the ability you seek...
One solution for applications with webviews is to run them in the iOS Simulator, and connect to that with the remote-debugger in macOS Safari. This is off-topic but maybe the one or other could benefit.
http://hiediutley.com/2011/11/22/debugging-ios-apps-using-safari-web-inspector/
Or use NetCat for iOS... not the most perfect solution, but at least you see what's going on.
I have created a simple iOS program that compiles without a hitch and runs great on an iPad simulator. The same program cannot be compiled when I tell XCode 4 to use my attached iPad device. The problem appears to be that several header files cannot be located when I try to use the attached iPad.
Here are the header files that cannot be located on the iPad device (this is excerpted from the relevant include statements):
#include <sys/socketvar.h>
#include <netinet/tcp_fsm.h>
#include <netinet/tcp_var.h>
So, for example, the error messages I'm getting are similar to
Sys/socketvar.h: No such file or directory
Please don't be side-tracked by the file names...I'm doing some rather low-level socket-related things in my program and was unable to utilize higher-level APIs provided by Apple.
My question is: what gives? I.e., why am I able to run this program (utilizing the three header files noted above) on an iPad simulator, but not an actual iPad? Also, is there some other location at which these header files can be referenced on a physical iOS device?
Thanks for the feedback--the solution was to simply spend some time walking the header file dependencies and manually recreate the missing files. In the end, there were seven (not the end of the world to wrangle by hand) and my program compiles and executes without a hitch on both an iPad simulator and physical device.
I would definitely prefer better parity between the header files available on a physical iOS device and the simulators, though! To be fair, however, I may be in a very small subset of developers who actually need to work with such low-level networking APIs.