Some initial support was added in r12814 just now.  This makes it
compile and able to run small programs on OSX 10.8.  Be warned however
that it still asserts with bigger apps, and 32 bit programs are not
checked properly at all (most errors are missed by Memcheck).

Feedback welcomed.  Especially if you have small test cases that cause
it to assert.

Any update on Mountain Lion support? I'm running 3.9.0-r13189 and it says it finds leaks in snprintf which seems a bit weird, but it still finds some real leaks so it's not completely useless.

Just to note that

(1) I'm using this as the central "Make V work on OSX 10.8" properly
    bug

(2) I made some progress in the past couple of days and am now able to
    run large graphical applications (Calculator, Textedit, Firefox)
    in 64 bit mode, without crashing.  The fixes are not yet in a
    state where they can be committed, but I hope to get them to that
    point in the next few days.

I don't suppose you have a private repo/branch somewhere with your current code to try before it hits valgrind trunk?

I pushed all the fixes I have at the moment in to the trunk (right
now, r13531).  It's somewhat usable for graphical applications --
Memcheck can find possible bugs in Firefox, for example -- but still
very kludged up and not very satisfactory.

Excellent, now my GTK application starts, but as soon as the application decides to go apeshit, valgrind gets stuck in an infinite loop:

==22253== Invalid read of size 1
==22253==    at 0x4325F6: gtk_tree_view_column_button_event (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0x2370DB: _gtk_marshal_BOOLEAN__BOXEDv (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0xD93603: _g_closure_invoke_va (in /Users/dsvensson/abraca-target/inst/lib/libgobject-2.0.0.dylib)
==22253==    by 0xDB8FFC: g_signal_emit_valist (in /Users/dsvensson/abraca-target/inst/lib/libgobject-2.0.0.dylib)
==22253==    by 0xDBA941: g_signal_emit (in /Users/dsvensson/abraca-target/inst/lib/libgobject-2.0.0.dylib)
==22253==    by 0x44CB9C: gtk_widget_event_internal (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0x44C283: gtk_widget_event (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0x46129F: gtk_widget_send_focus_change (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0x4763EE: do_focus_change (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0x476C7C: gtk_window_real_set_focus (in /Users/dsvensson/abraca-target/inst/lib/libgtk-3.0.dylib)
==22253==    by 0xD9A282: g_cclosure_marshal_VOID__OBJECTv (in /Users/dsvensson/abraca-target/inst/lib/libgobject-2.0.0.dylib)
==22253==    by 0xD93C19: g_type_class_meta_marshalv (in /Users/dsvensson/abraca-target/inst/lib/libgobject-2.0.0.dylib)
==22253==  Address 0xaaaaaaaaaaaaab5a is not stack'd, malloc'd or (recently) free'd
==22253==
==22253== Signal 11 being dropped from thread 0's queue
==22253== Signal 11 being dropped from thread 0's queue
==22253== Signal 11 being dropped from thread 0's queue
==22253== Signal 11 being dropped from thread 0's queue

Last message will print forever.

Try running with --smc-check=all.  MacOS now generates so much code
at runtime that not using it is really asking for trouble.

That said, I know it is still seriously borked and needs perhaps another
week's worth of work.

Try running with --smc-check=all.  MacOS now generates so much code
at runtime that not using it is really asking for trouble.

That said, I know it is still seriously borked and needs perhaps another
week's worth of work.

Any updates on this? Just built today and here's the output of a run with an empty main(): http://d456c2b06144a9cf.paste.se/

Right.. missing in the above output is the following:

$ file test
test: Mach-O 64-bit x86_64 executable

So it is indeed a 64bit binary. Just noticed the 32bit warning in the beginning of the execution and wanted to make it clear that this is not a problem in this case.

Should support for OS X 10.9 be a separate ticket? The GM version is available from developer.apple.com now.

I just pulled the trunk from svn onto Mavericks and configure says:

checking for the kernel version... unsupported (13.0.0)
configure: error: Valgrind works on Darwin 10.x and 11.x (Mac OS X 10.6/7)

Is there a way to override the check and try?

Benson: Just tried overriding and removing some deprecated fcntl flags which got it to compile. When running a test application a call (used by the OS) to fcntl with F_ADDFILESIGS as argument causes valgrind to bail. sys/fcntl.h seems to indicate that it's similar to F_ADDSIGS, but naively treating them the same way does not work. Guess there's something new with application signatures in Maverick. New development needed rather than just overriding a version check. Worth noting is that I have basically no idea what I'm doing so take what I say with a big grain of salt.

r13523 added a fix for darwin-amd64. The same fix is needed for darwin-x86.

Hi Mark,
That fix was cross-ported for darwin-x86 in r14888.

Looking through the comments here, are there any OS X 10.8 Mountain Lion *specific* issues any more?

I know there remain a number of OS X platform issues, but I'm kind of inclined to close this bug report now that Valgrind can be built and run on the OS X 10.8 platform without issues.

To be clear: this is not me saying that we are abandoning support for OS X 10.8 and earlier. I will continue to:
1. Address the regression test failures, with issues being tracked in separate bug reports; and
2. When the above are resolved that will apply across many OS X releases.

Thoughts? Please shout out if there are an pressing 10.8 specific bugs.

I'm going to mark this as completed. Based on the regression test suite there are no further OS X 10.8 specific bug reports.