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.
Related
I'm working on an app that, due to restrictions that are beyond my control, is being built as an x86_64 app using an outdated macOS SDK (in this case the macOS 10.15 SDK).
It runs fine on an Apple Silicon mac using Rosetta 2, but the app needs to get the current version of macOS, and the available APIs lie to it under these conditions, consistently reporting the version is 10.16 when really it should be macOS 11.x or 12.x.
In other circumstances where the system API lies, I've been able to get the real info using sysctl, but in this case calling sysctlbyname("kern.osproductversion", ...) still lies to my app and reports 10.16.
How can I get the true version of macOS under these circumstances?
The only solution I've found so far is to launch the sysctl command line utility as a separate process and use it to query the system version. Here's a C++ implementation using Qt:
QProcess *p = new QProcess;
p->setProgram("/usr/sbin/sysctl");
p->setArguments({"-b", "kern.osproductversion"});
p->start();
if (!p->waitForFinished(2000)) {
// handle unlikely error here
}
QByteArray systemVersion = p->readAllStandardOutput();
On the bright side, this only ever needs to be executed once as the system version presumably won't change over the course of a process's life. Nonetheless I'll leave this question open in case someone has a better solution.
I'm trying to install/update my clang from Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn) to clang version 3.3. I've downloaded the pre-compiled binaries into usr/bin/, as suggested by other posts (How can I update clang to 3.3 on Mac OS X 10.6).
The point of this installation/update is to be able to use C++ code (not written by me, and written for a newer machine OS 10.8.x) on my mac. I would preferentially use Xcode to update this, but unfortunately, Apple has not made the necessary version of Xcode available for free without a developer's subscription.
I've edited my PATH and LD_LIBRARY_PATH to include clang3.3/bin/ and clang3.3/lib, but I get an "Illegal Instruction" error and it's not clear to me why this is.
What I'd really like is to try the whole process again from the beginning with a step-by-step outline of the process, like is seen here (How to install clang pre-built binaries ubuntu 12.04), except for Mac OSX system, not Ubuntu.
I realize there are some previous threads that ask almost the same question, but I am asking specifically for these versions (and from a standpoint that includes very little experience installing via terminal/understanding pathways/etc.).
Thanks for any help.
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.
I downloaded LibC source from opensource.apple.com, but since it's part of one monolithic library /usr/lib/libSystem.B.dylib would I have to somehow rebuild the entire thing?
I have a BSD command line program, ported from Linux. I want to be able to set breakpoints in LibC functions and step through. I'm trying to close in on what seems to be heap corruption in my program (which doesn't occur on Linux - I've already ported back to Linux and run memcheck there.)
Have you take a look at the Kernel Debug Kit from Apple (http://developer.apple.com/sdk/) ? I know that it contains kernel symbols, but I am not sure if libc is part of the SDK.
You can build Valgrind yourself - either use the last version released on 10.5, or look on the bug tracker for the Snow Leopard support bug, which has a patch.
Alternately, try the memory debugging tools in the malloc(3) manual.
I've been building a basic Cocoa application with Core Data and Interface Builder, and no extra coding, frameworks, or header files. I sent it to someone to test on their machine (a last-gen G5 iMac), and they got a message saying that their machine couldn't run it. I discovered the switch to compile for PPC, so I built a PPC version of the application to try out, and that produced the following error message:
You cannot use this version of Application on this version of Mac OS X.
I'm running Xcode 3.2.1, Interface Builder 3.2.1, and OS 10.6.2. The conversation with my tester was a bit confusing; at first it sounded like she only had Tiger on her machine, saying Leopard was incompatible (I corrected and said that Leopard should be, it's Snow Leopard that isn't), and then by the end of the conversation she was about certain that her machine was running Leopard, but had already shut it off by then. So I'm not sure which version of OS X is on the offending iMac, but it's the latest version of either 10.4.11 or 10.5.8 (the tester is in a remote location, so I can't verify personally at the moment).
What can I tweak to try and improve compatibility on my tester's machine?
If they're seeing that message, it's most likely because your app has the LSMinimumSystemVersion key (Minimum system version) set in the Info.plist. You should take this key out or set it to the actual the minimum OS X version you support.
Once you do this, you may well run into the next problem. (Probably a dynamic linker error as a result of using a framework or API that didn't yet exist on 10.4 or 10.5.)
The main problem here is that you're sending it out to a system where you haven't actually tried it. If you plan to support 10.4, 10.5, or both, I highly recommend that you find a spare hard drive, partition it up, and install 10.4.11 and 10.5.8. There are many issues that will crop up on older OS's and if you haven't tried it yourself, it's unlikely it will work smoothly on the first try.