I have been able to run the Static Analyzer on my code fine for months. All of a sudden now I am getting the error:
<command line>:0:0 Analyzer skipped this file due to parse errors
Not sure how to diagnose.
The first tile it skips is:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.1.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGPDFContext.h:0:0 Analyzer skipped this file due to parse errors
I get these errors too if I try to use it when the target is set to the simulator, but if I switch the target to the device then it works.
Typically, this is a result of a syntax error or something else that is preventing your code from compiling.
Because you are only seeing errors when you go to analyze your code, not when it compiles, I bet that you are using the GCC compiler for your main application builds. Clang / LLVM has a bug in the iOS 4.1 SDK that causes compilation errors when targeting the Simulator, but not the device. The Clang Static Analyzer is probably exhibiting this same bug.
The solution I provide in my answer to the above-linked question should work to fix this as well. However, it may lead to compilation errors when you switch back to build your application with GCC, so I recommend switching your compiler over to LLVM. Unless you are using C++ code, I recommend using LLVM for iPhone projects anyway, due to the minor performance boosts you can get in your compiled application with it.
Related
Not true for all new iOS 5 methods but I've found out that calling UINavigationBar's setBackgroundImage:forBarMetrics: method will trigger an 'instance method not found' warning if the deployment target is under 5.0. This is even though I am linking with the SDK 5.0.
More importantly the enum UIBarMetrics used as a parameter there is reported as an 'undeclared identifier' and this will trigger a compiler error.
Any idea why this is so? I realized the code will not work if the deployment target is under 5.0 but I'm checking if UINavigationBar responds to that selector at run time, so everything should be ok. I don't understand the compiler error though.
EDIT:
This only happens when compiling for a device, and when a device is actually plugged in (the device I've tested with runs iOS 5.0.1).
Well, I figured out the mystery. I manage to fix the problem by deleting SDK 4.3 (I had that one copied over from Xcode 3 since it doesn't come by default with the latest Xcode+SDK package and I was using it for another legacy project).
I still can't explain why having both SDKs caused the error since I was clearly compiling with the latest SDK.
I have been developing a monotouch opengl iphone game for some weeks now. As recently as yesterday, it was building and running properly on my test hardware (an iPhone 4). But when I loaded the project yesterday, it gave me the compiler error:
Framework 'Mono for iPhone' not Installed.
I can't think of any reason for this, I had not changed my system or source code. Luckily Monodevelop was already harassing me with a download link for the latest api download. I installed and the error went away. But instead, I now get a runtime error when the app starts http://screencast.com/t/EXyNqqhNoEsu :
System.ExecutionEngineException has been thrown. Attempting to JIT compile method ... FirstOrDefault ... while running with --aot-only.
This occurs while trying to create a new DataContractSerializer to load some XML settings: http://screencast.com/t/4SDzU5ygg
This compelled me for the first time to change the Linker behavior setting under the app's project options. It was set to 'Don't link', as it has been. When I switch to 'Link SDK assemblies only', it runs without the above exception.
This would be great, problem solved, except that it takes almost half an hour (!) to compile and deploy to the phone in this mode. The build output sits on 'Linking SDK only for assembly...'. Is this normal? I don't think I can keep my sanity with build times that long. Even 'Don't Link' takes about five minutes which is a grueling pace when you're trying to troubleshoot.
To reiterate, this is code that was working every day for weeks, and to my knowledge has not been changed from its working state. Does anyone know why this error is occurring now, and what a resolution might be to continue using the 'Don't Link' option?
Framework 'Mono for iPhone' not Installed.
For some reason MonoDevelop could not find your MonoTouch installation. I can't say why, but restarting MonoDevelop and checking the MD preferences for SDK Locations (and fix the path if MonoTouch was not found) would have been the best options to try.
System.ExecutionEngineException has been thrown. Attempting to JIT compile method ... FirstOrDefault ... while running with --aot-only.
MonoTouch 4.2[.1] can sometime throw a ExecutionEngineException when the "Don't link" linker option is selected. This bug was fixed and will be part of future releases of MonoTouch.
FWIW Link SDK assemblies is the default and should always be used for device builds. The linker will produce much smaller applications and it also allows faster builds in most circumstances (because the linker can save 100kb faster than the AOT compiler can process that 100kb).
If you hit a case where the linker takes a very long time then something is wrong (or at least weird) in your project. Please take the time to fill a bug report at http://bugzilla.xamarin.com so we can investigate why this takes so long.
I have an monotouch application that includes an objective-c static library. The application runs correctly on the simulator, but when I try run the app on my iPhone 3GS, it crashes on startup. These are the steps that I have taken to try get it working:
Compiled the static library in Xcode with Device specified and active architecture set at armv6 and at armv7 (I am not sure which is correct, but I tried both and neither worked).
Under the project info I set code signing identity to my developer key.
In MonoDevelop I have included the static library in the application project options by setting the additional monotouch arguments under iPhone build to have the following value (this is identical to what is set for iPhoneSimulator):
-v -v -v -gcc_flags "-lstdc++ -I${ProjectDir}/Ultralite/Include -L${ProjectDir}/Ultralite -lUltralite -force_load ${ProjectDir}/Ultralite/libUltralite.a"
When I try run the application, it crashes on startup (so the application screen does not even appear). In MonoDevelop all that I see is the following exception message:
Exception of type 'Mono.Debugger.Soft.VMDisconnectedException' was thrown.
All that I see in the device log in Xcode is the following:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x2fd00f24
If I remove the -gcc_flags option from the project options, then the application starts up, but crashes at the first attempt at accessing the static library. So it is definitely something to do with the static library that is causing the application to crash on startup.
I have no idea where to even begin with solving this, and so really need some help on this one. Anyone got any ideas as to what is wrong with the static library that I am including, or know where I can get more information about what is going wrong? The KERN_PROTECTION_FAILURE message in the crash report is really not giving me much to work with.
Update:
I have created a simple Hello World application which has one button, which when clicked calls a method sayHello in a static library. Even with this basic example I encountered the same problem; namely that it runs on the simulator but not on the actual device. I have uploaded my helloworld example to github. I would really appreciate it if someone could help me in getting this working. Here is the Hello World sample:
https://github.com/BruceHill/HelloWorld
This includes a folder for the basic application, a folder with the objective-c static library and then finally a folder for the btouch definition. I call btouch with the parameter -outdir=. to build Messaging.g.cs and UltraliteManager.g.cs which I then include in the MonoTouch application.
I had to make two changes to get this working correctly on the iphone:
linker behavior in the build options had to have the option Link all assemblies set.
I had to add -framework Security to the gcc_flags.
So additional monotouch arguments under the build options had to have the following value:
-v -v -v -gcc_flags "-framework Security -lstdc++ -I${ProjectDir}/Ultralite/Include -L${ProjectDir}/Ultralite -lUltralite -force_load ${ProjectDir}/Ultralite/libUltralite.a"
The reason I had to add the Security framework is that it seems MonoTouch includes this framework when Don't link is specified in the build options, but does not include it when the other two options are set. I determined this by comparing the build logs for the different options.
Open XCode Organizer. Plug in your device. Then look at the crashes. The data will symbolicate and you'd at least see at what point it failed.
I had a similar problem with MonoTouch linking a 3rd party library through BTouch. Same exception types and codes.
You have to get the source code for that 3rd party library and compile it with THUMB disabled. XCode has this option, just do a search for THUMB in the options. libUltralite.a will end up being a little bit larger in size.
Try adding "-ObjC" to your linker flags.
Update:
There seems to be a some issues regarding static libraties. You may also try to use the -all_load flag: What does the -all_load linker flag do?
I have a superweird problem:
I get a crash (EXC_BAD_ACCESS) when running my app with Release as active configuration on my 3.1.3 iPhone 3G. (works well in debug configuration or in simulator , works perfectly on device running iOS4).
My first guess was one setting in the Release configuration was erroneous/missing. In order to test it I just made a duplicate of my debug configuration and surprisingly I get the same error (although configuration is just a copy of the one working).
I don't understand why, with configurations that are supposed to be the same, one is working and not the other one.
If someone want to enlighten me, I am banging my head against the wall.
Thank you
NOTE: base SDK is 4.0 and deployment target is 3.0
Perhaps you have an unassigned local variable. Object-C follows how C does this. So in a release version you cannot assume that any local variable is initialised to 0 whilst in debug you can (in this case I would guess a pointer).
EDIT:
Pass -Wuninitialized to the compiler (or better -Wall) for the compiler to warn on these Apple gcc man page Note only works if optimizer is on.
You should check for memory leaks and handling of memory warnings. The amount of memory is probably the biggest difference between the environments you quote.
In another scenario I once found out that the simulator was faster, and therefore a certain race condition didn't show up, which did show up on the device. That's the second difference in the environments you quote: speed.
Try to pinpoint your crash and investigate from there. NSLog all didReceiveMemoryWarnings. Look for places where you made assumptions, i.e. about static information.
I fixed the problem.
It was three20 library fault. I had updated to the master branch that support iOS 4 but unfortunately this breaks support for 3.1.3. (thing that is not documented apparently)
Anyway I found this post that helped me to spot the problem. I just had to apply this patch and then I was able to run my project on 3.1.3 devices and iOS4 ones
Weird thing: why was it crashing when I was initializing a UIActionSheet (on a line of code not related at all with the Three20 lib)?
Thank you for your help.
When I switch the Compiler Version to Clang llvm 1.0 in existing projects I get the following build error when Precompiling the *.pch file:
error: can't exec '/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc-4.2' (No such file or directory)
Is there another setting I need to change to get my project to work with the new compiler?
(I did try a clean all targets)
Update:
To clarify:
Since the new compiler does in fact work with new projects, the issue is not that my system is missing anything.
Additionally, Xcode should not even be trying to find llvm-gcc-4.2 as the whole point is that I switched from that compiler to the new one, Clang llvm 1.0. This is what has led me to believe there is still another setting to be changed.
Thanks to fbereto for his suggestion. The actual answer lies in the comments.
If you look in path specified by the error you will not find an LLVM compiler (llvm-gcc-4.2) for the iPhone device:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/
That being said one does exist for the iPhone Simulator:
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/
All this to say that while it may be possible to compile your iPhone App under LLVM for the Simulator, no equivalent tool exists for the device itself.
(Answer detailed in comments below.)