What is the "Illegal Instruction: 4" error and why does "-mmacosx-version-min=10.x" fix it? - macos

I get Illegal Instruction: 4 errors with binaries compiled with GCC 4.7.2 under Mac OS X 10.8.2 ("Mountain Lion"), when those binaries are run under Mac OS X 10.7.x ("Lion") and earlier versions. The binaries work properly under Mac OS X 10.8.x.
I added -mmacosx-version-min=10.5 to my compile flags and this seems to help resolve the issue for 10.5.x, 10.6.x and 10.7.x clients, whatever that issue is.
Which gets to my question(s):
What is the Illegal Instruction: 4 error?
Why does -mmacosx-version-min=10.x fix this specific error on 10.x and greater clients?
I'd like to apply this fix to my makefiles, but would like to know what it is doing before I pull the trigger. (Will I have larger binaries? Do I still have 64-bit binaries? Are there gotchas with this approach I should know about? Unintended side-effects? Etc.)

From the Apple Developer Forum (account required):
"The compiler and linker are capable of using features and performing optimizations that do not work on older OS versions. -mmacosx-version-min tells the tools what OS versions you need to work with, so the tools can disable optimizations that won't run on those OS versions. If you need to run on older OS versions then you must use this flag.
"The downside to -mmacosx-version-min is that the app's performance may be worse on newer OS versions then it could have been if it did not need to be backwards-compatible. In most cases the differences are small."

The "illegal instruction" message is simply telling you that your binaries contain instructions the version of the OS that you are attempting to run them under does not understand. I can't give you the precise meaning of 4 but I expect that is internal to Apple.
Otherwise take a look at these... they are a little old, but probably tell you what you need to know
How does 64 bit code work on OS-X 10.5?
what does macosx-version-min imply?

I'm consciously writing this answer to an old question with this in mind, because the other answers didn't help me.
I got the Illegal Instruction: 4 while running the binary on the same system I had compiled it on, so -mmacosx-version-min didn't help.
I was using gcc in Code Blocks 16 on Mac OS X 10.11.
However, turning off all of Code Blocks' compiler flags for optimization worked. So look at all the flags Code Blocks set (right-click on the Project -> "Build Properties") and turn off all the flags you are sure you don't need, especially -s and the -Oflags for optimization. That did it for me.

I found my issue was an improper
if (leaf = NULL) {...}
where it should have been
if (leaf == NULL){...}
Check those compiler warnings!

I got this error when attempting to build with Xcode 10. It appears to be a bug in the Swift compiler. Building with Whole Module Optimization on, resolves the issue: https://forums.swift.org/t/illegal-instruction-4-when-trying-to-compile-project/16118
This is not an ideal solution, I will continue to use Xcode 9.4.1 until this issue is resolved.

In my case, I got this while overloading
ostream & operator << (ostream &out, const MyClass &obj)
and forgot to return out. In other systems this just generates a warning, but on macos it also generated an error (although it seems to print correctly).
The error was resolved by adding the correct return value. In my case, adding the -mmacosx-version-min flag had no effect.

I recently got this error. I had compiled the binary with -O3. Google told me that this means "illegal opcode", which seemed fishy to me. I then turned off all optimizations and reran. Now the error transformed to a segfault. Hence by setting -g and running valgrind I tracked the source down and fixed it. Reenabling all optimizations showed no further appearances of illegal instruction 4.
Apparently, optimizing wrong code can yield weird results.

Related

Gem5 on Mac OSX, build issue (errors)

I am new to gem5 and I am trying to install the simulator on my iMac pc (OSversion: High Sierra 10.13.6).
All the dependencies specified on the site have been installed to the correct version. The problem i am currently stuck with is that when i try to first compile M5 in the gem5 directory with 'scons build/ARM/gem5.opt', it stopped with errors mostly being:
**/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3656:5: error: destructor called on non-final
'Stats::BinaryNode<std::__1::multiplies<double> >' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]**
__data_.second().~_Tp();
^
I couldn't find any relevent answers regarding this. I hope if there are any amazing MAC gem5 developers out there can help me with this.
cheers!
I mailed to Mr Andreas Sandberg. The answer worked for me:
"I think the compiler version you are using uses more aggressive warnings than default (and possibly a newer C++ standard than we normally use). I would suggest disabling -Werror and see if that makes a difference."
Try disabling -Werror with the next command line :
export CFLAGS="-Wno-error"
Hope work for you.

Running mach_inject with Qt in OSX Mountain Lion

On OSX Mountain Lion I'm able to compile mach_inject and the included test project. That works as expected with injection functioning perfectly.
I'm now trying to use the same mach_inject framework from a Qt project, compiled from QtCreator. I've tried both clang and gcc compilers.
Everything compiles and the application runs, but when calling mach_inject, I get the error:
mach_inject failing.. (os/kern) invalid address
Tracing mach_inject, the failure occurs at the last step, when it calls thread_create_running.
Does anyone know what the problem is here? I'm assuming it's something to do with the compiler options provided by Qt against those used by XCode, but could be totally wrong!
Thanks.
The problem turned out to be a 32 / 64 bit incompatibility - as (naturally) you can't inject a 64bit bundle into a 32 bit app!
If anyone else has similar problems, debugging into the mach_inject_bundle_stub can be of use, as the same error from the kernel can be presented due to other issues.

Why do OCaml binaries crash on Mac OS X 10.8 (Mountain Lion)?

OCaml programs which worked perfectly on Lion fail on Mountain Lion, segfaulting on startup in OCaml runtime code:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff908e1f88 in large_malloc ()
There appears to be a widespread problem with the native-compiled (ocamlopt) OCaml runtime when backtraces are enabled which is new to Mountain Lion. This same crash affects the startup of any OCaml binaries which are:
Native compiled (as opposed to bytecode)
Run with backtraces enabled (e.g. via OCAMLRUNPARAM=b)
This even includes parts of the OCaml compiler toolchain, itself, which will suddenly stop working after an upgrade to 10.8.
This still affects the OCaml SVN trunk (4.01.dev) as of 2012-07-19.
The workaround is to disabled backtraces when working with native compiled binaries (unset OCAMLRUNPARAM, or remove b from your parameter string).
update:
The underlying bug appears to be due to insufficient stack alignment in the OCaml runtime implementation. Since the originally post, this is now being tracked and fixed on the OCaml bug tracker. For now, however, the workaround remains the only simple choice.
The problem may be solved, there's an explanation and a patch here in OCaml's bugtracker.

Mac SDK: using latest SDK but ensuring backwards compatibility with earlier deployment target

As always when Apple updates OS X, the latest XCode 4.4 dumps the older (10.6) SDK and I find myself needing to use the 10.7 SDK (or 10.8 I suppose) and setting my deployment target to 10.6 to maintain compatibility.
I prefer linking to the older SDK because I know that I cannot by mistake introduce calls to APIs that do not yet exist. Something that I found myself doing regularly when I last tried the inverse approach.
What I find myself doing is that I use the code completion feature in XCode to choose the "right" call for a simple class like NSWorkspace, then everything works fine during development, I forget about it and when I release a new version: Kaboum! The whole application explodes on earlier OS X releases at run-time; often in those hard-to-reach places :-)
Or at least this was the situation for me a few years back.
Surely, by now there's a way to either:
making sure you don't introduce API calls that are not yet available in your deployment target even if though they are defined in the SDK
detecting such calls during build or static analysis time
I'm sure I've missed something, somewhere along the line.. Please enlighten me!
Best regards,
Frank
Surely, by now there's a way to either:
making sure you don't introduce API calls that are not yet available
in your deployment target even if though they are defined in the SDK
detecting such calls during build or static analysis time
No there is not. Yes, you should open a radar (bugreport.apple.com) against it. If you like, you can dupe mine: rdar://11985733
Yes, the only viable solution, despite Apple's recommendation, is to copy the old SDKs and link against them.
I spent quite some time talking with the Xcode team about exactly this issue at WWDC 2012. They agreed that it's broken. There is not currently a plan to fix it. Escalating radar's is how we influence Apple on these things.
I'm generally copy SDK from older versions to the newer one so that compiler will blain me if i use something not supported.
Also you can simply look at Quick Help when calling some methods that you are not sure about, like in screenshot you can see that launchApplicationAtURL method is only available from 10.6
I've had this annoying problem on iOS too. It's actually even more annoying on iOS as the user has to sync their device with iTunes and enable crash report sending before the crash report gets sent unlike Mac OS X where you don't need to do all that. Recently, I managed to add a compile-time check for checking APIs against older versions of the SDK. I'll first explain how I did it for iOS first and then try and help you to adapt this technique for Mac OS X. I don't code much for Mac atm so I can only really guide you in the right direction from my experience with iOS but I'll test my suggestions later today once I get back from work and give a definite answer.
So here's what I did for iOS:
I first had to get the older Simulator SDK I wanted to get. I could easily get this by downloading older Xcode 3 (not 4) versions which included the SDK needed.
I next had to install the SDK. This wasn't too hard, so I won't explain much here. But the SDKs are stored in the Packages folder. This folder is clearly visible in earlier Xcode 3 versions but is hidden in later versions. You can easily open it anyway through Terminal. Also, after the change in Xcode 4.3 where the Developer folder moved to within Xcode.app, so I had to install the SDK into a tmp folder and move the SDK into Xcode.app yourself. I would then need to restart Xcode if I had it open.
After that, I duplicated my debug configuration in your project and named it, in my case, something like iOS 4.3 API Check or something like that - doesn't really matter. Then I changed the Base SDK of this new configuration to the old SDK which I installed. The SDK I installed was not listed though so I had to select other and enter, again in my case, iphonesimulator4.3.
Finally, when I needed to check against older versions of the SDK, I changed the configuration for the Run <appname>.app in my project scheme to my iOS 4.3 API Check configuration. And there we go, a compile-time check against iOS 4.3.
As for Mac OS X, I'm sure you can achieve the same goal with this same method. There isn't Simulators for the Mac SDK so I think the regular SDK will work for this. As for getting the older SDK, if you have Xcode 4.2 still installed (after Xcode 4.3 changed it so the Developer folder is within Xcode.app) then you should find the 10.6 SDK there. If you don't, I'd imagine that Apple has a similar thing to iOS where the SDK downloads are available in the Dev Center or somewhere on the internet...
As for setting the Base SDK, if it's not listed then I think the name is MacOSX10.6 or whatever version you are after.
Everything else should be the same, but as mentioned earlier, I'll test this method later today and edit my answer to give a more definite answer but I would imagine this method would work for the Mac SDK.
i also assumed that the compiler will warn me about "too new" API usage for the deployment target OS version. but it turned out that the compiler doesn't warn you about it by default. one of the reasons might be you could still use the new API by checking the availability during runtime with "respondsToSelector:", for example, on a newer OS version even when the deployment target version was older. you would need to add the compiler option -Wpartial-availability which is available on Xcode 7.3+ (to be confirmed) in order to get the "warning: 'something' is partial: introduced in macOS 10.x" warning message.
on macOS 10.12.3 with Xcode 8.2.1:
$ cat foo.m
#include <Foundation/Foundation.h>
BOOL foo()
{
return [#"foo" containsString:#"bar"];
}
$ cc -mmacosx-version-min=10.9 -Wpartial-availability foo.m -c -o foo.o
foo.m:5:20: warning: 'containsString:' is partial: introduced in macOS 10.10 [-Wpartial-availability]
return [#"foo" containsString:#"bar"];
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:132:1: note:
'containsString:' has been explicitly marked partial here
- (BOOL)containsString:(NSString *)str NS_AVAILABLE(10_10, 8_0);
^
foo.m:5:20: note: explicitly redeclare 'containsString:' to silence this warning
return [#"foo" containsString:#"bar"];
^
1 warning generated.
see also: Is there a way for XCode to warn about new API calls?
I check my code by hacking around Availability.h to get the compiler to flag weak-linked symbols as warnings/errors. In my current (Xcode 5/llvm) incarnation, I'm using the code below. It warns whenever I use a symbol introduced in iOS 6.0 or later. I think it's fairly self-explanatory. The macros seem to need updating at each and every SDK update, so tread carefully. Oh, and you loose deprecation warnings too, so I only use this once in a while to double-check my conditional code.
#undef __NSi_6_0
#define __NSi_6_0 deprecated=1.0
#undef __NSi_6_1
#define __NSi_6_1 deprecated=1.0
#undef __NSi_7_0
#define __NSi_7_0 deprecated=1.0
#undef __NSd_6_0
#define __NSd_6_0
#undef __NSd_6_1
#define __NSd_6_1
#undef __NSd_7_0
#define __NSd_7_0
See also http://iphone.m20.nl/wp/2013/10/xcode-5-and-flagging-weak-linked-unavailable-symbols-from-a-newer-sdk/
Since Xcode 9 there is a build setting doing exactly this, turning on the warning -Wunguarded-availability and/or -Wunguarded-availability-new.
The former warns when an API newer than the deployment target is used. The latter only warns when an API introduced newer than macOS 10.13 or iOS 11 is used in a similar manner.
For an existing project, the former is off by default, and the latter is on by default.
This setting is called “unguarded availability” within Xcode’s build settings pane, and you can choose one of Yes, Yes for all versions, or No from the GUI.
For more details, see the WWDC17 session 411, “What's New in LLVM”, https://developer.apple.com/videos/play/wwdc2017/411/ .

How to avoid XCode framework weak-linking problems?

I'm building an application that takes advantage of Mac OS X 10.6-only technologies, but without giving up backwards compatibility to 10.5 Leopard.
The way I do this is by setting the 10.6 SDK as the base SDK, weak-linking all frameworks and setting the deployment target to 10.5 as described in:
http://developer.apple.com/mac/library/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
This works fine; before making a call that is Snow Leopard-only I need to check that the selector or indeed the class actually exist. Or I can just check the OS version before making the call.
The problem is that this is incredibly fragile. If I make a single call that is 10.6 only I blow Leopard-compatibility. So using even the normal code code completion feature can be dangerous.
My question: is there any way of checking which calls are not defined on 10.5 before doing a release build? Some kind of static analysis, or even just a trick (a target set the other SDK?) would do.
I obviously should test on a Leopard machine before releasing anything, but even so I can't possibly go through all paths of the program before every release.
Any advice would be appreciated.
Best regards,
Frank
You could change the target SDK to 10.5. The compiler will then output warning: definition for '-snowLeopardOnlyMethod:' not found messages.

Resources