Bug 326724

Failing here as well. I'm not even sure valgrind supports Mountain Lion or Lion, it's pretty far behind.

It worked great on my OSX 10.7 machine (whatever cat that was).  Moving to a new laptop has forced a move to 10.9.  But the absence of valgrind makes the laptop much less useful (retina display and other niceties notwithstanding)!  Does anyone have a concrete sense of what needs to be done to remedy this?

Created attachment 83536 [details]
Patch to add preliminar support for OS X Mavericks.

This patch allows valgrind trunk (r13712) to compile on Mac OS X Mavericks. The patch does the following:

- Added Mac OS X 10.3 to configure.ac and defined DARWIN_10_9
- Removed fcntl(2) flags F_READBOOTSTRAP and F_WRITEBOOTSTRAP from OS X Mavericks build since they no longer exist
- Added mach__15 trap support for OS X Mavericks avoiding "unimplemented (by the kernel) syscall: mach: 15! (ni_syscall)"
- Added mach__24 trap support for OS X Mavericks avoiding "unimplemented (by the kernel) syscall: mach: 24! (ni_syscall)"

However, valgrind complains for too many errors even on a very simple C program (int main() { }). See below:

==38381== Invalid write of size 8
==38381==    at 0x2C6A25: create_scalable_zone (in /usr/lib/system/libsystem_malloc.dylib)
==38381==    by 0x2D43ED: _malloc_initialize (in /usr/lib/system/libsystem_malloc.dylib)
==38381==    by 0x2D527D: malloc (in /usr/lib/system/libsystem_malloc.dylib)
==38381==    by 0x7FFF5FC12D4F: malloc (in /usr/lib/dyld)
==38381==    by 0x7FFF5FC1A3BD: operator new(unsigned long) (in /usr/lib/dyld)
==38381==    by 0x7FFF5FC090EC: std::__1::__split_buffer<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*), std::__1::allocator<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)>&) (in /usr/lib/dyld)
==38381==    by 0x7FFF5FC08A44: std::__1::vector<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*), std::__1::allocator<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)> >::insert(std::__1::__wrap_iter<char const* (* const*)(dyld_image_states, unsigned int, dyld_image_info const*)>, char const* (* const&)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==38381==    by 0x7FFF5FC0426B: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==38381==    by 0xEB8F0: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==38381==    by 0xEB6B1: _dyld_initializer (in /usr/lib/system/libdyld.dylib)
==38381==    by 0xDA9D: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==38381==    by 0x7FFF5FC11C2D: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==38381==  Address 0x6e30b8 is not stack'd, malloc'd or (recently) free'd

For a total of:

==38386== ERROR SUMMARY: 44167 errors from 1103 contexts (suppressed: 0 from 0)

Since this is my first patch, I would appreciate some help from more experienced valgrind developers to keep going. Thanks.

*** This bug has been confirmed by popular vote. ***

(In reply to comment #3)

> However, valgrind complains for too many errors even on a very simple C
> program (int main() { }). See below:
> 
> ==38381== Invalid write of size 8
> ==38381==    at 0x2C6A25: create_scalable_zone (in
> /usr/lib/system/libsystem_malloc.dylib)
> ==38381==    by 0x2D43ED: _malloc_initialize (in
> /usr/lib/system/libsystem_malloc.dylib)
> ==38381==    by 0x2D527D: malloc (in /usr/lib/system/libsystem_malloc.dylib)
> ==38381==    by 0x7FFF5FC12D4F: malloc (in /usr/lib/dyld)
> ==38381==    by 0x7FFF5FC1A3BD: operator new(unsigned long) (in
> /usr/lib/dyld)
The above looks like if the operator new and/or the malloc function is not being
replaced, which might cause the above problems and will after
for sure cause another bunch of problems (such as not able to find leaks etc).

(I do not have access to a Mac so cannot help to dig.
You might try to investigate what happens using --trace-redir=yes -v -v -v -d -d -d).

A quick look at the above and at include/pub_tool_redir.h, it might be the encoded name
of the library in which to replace malloc et al is not correct for 10.8:
#if defined(VGO_linux)
#  define  VG_Z_LIBC_SONAME  libcZdsoZa              // libc.so*

#elif defined(VGO_darwin) && (DARWIN_VERS <= DARWIN_10_6)
#  define  VG_Z_LIBC_SONAME  libSystemZdZaZddylib    // libSystem.*.dylib

#elif defined(VGO_darwin) && (DARWIN_VERS >= DARWIN_10_7)
#  define  VG_Z_LIBC_SONAME  libsystemZucZaZddylib   // libsystem_c*.dylib
as this last pattern does not match the lib in the trace above.

where VG_Z_LIBC_SONAME is used e.g. in
coregrind/m_replacemalloc/vg_replace_malloc.c e.g. in
#elif defined(VGO_darwin)
 ALLOC_or_NULL(VG_Z_LIBC_SONAME,      malloc,      malloc);
 ALLOC_or_NULL(SO_SYN_MALLOC,         malloc,      malloc);

You might also try to (temporarily) experiment with 
--soname-synonyms=somalloc=libsystem_malloc.dylib
(or maybe use wildcards).

Created attachment 83572 [details]
Patch to add preliminar support for OS X Mavericks (v2).

(In reply to comment #5)
> (In reply to comment #3)
> 
> The above looks like if the operator new and/or the malloc function is not
> being
> replaced, which might cause the above problems and will after
> for sure cause another bunch of problems (such as not able to find leaks
> etc).
> 
> (I do not have access to a Mac so cannot help to dig.
> You might try to investigate what happens using --trace-redir=yes -v -v -v
> -d -d -d).
> 
> A quick look at the above and at include/pub_tool_redir.h, it might be the
> encoded name
> of the library in which to replace malloc et al is not correct for 10.8:
> #if defined(VGO_linux)
> #  define  VG_Z_LIBC_SONAME  libcZdsoZa              // libc.so*
> 
> #elif defined(VGO_darwin) && (DARWIN_VERS <= DARWIN_10_6)
> #  define  VG_Z_LIBC_SONAME  libSystemZdZaZddylib    // libSystem.*.dylib
> 
> #elif defined(VGO_darwin) && (DARWIN_VERS >= DARWIN_10_7)
> #  define  VG_Z_LIBC_SONAME  libsystemZucZaZddylib   // libsystem_c*.dylib
> as this last pattern does not match the lib in the trace above.
> 
> where VG_Z_LIBC_SONAME is used e.g. in
> coregrind/m_replacemalloc/vg_replace_malloc.c e.g. in
> #elif defined(VGO_darwin)
>  ALLOC_or_NULL(VG_Z_LIBC_SONAME,      malloc,      malloc);
>  ALLOC_or_NULL(SO_SYN_MALLOC,         malloc,      malloc);
> 
> You might also try to (temporarily) experiment with 
> --soname-synonyms=somalloc=libsystem_malloc.dylib
> (or maybe use wildcards).

Phillippe, you were very helpful, thanks!

I zencoded the malloc library (it's libsystem_malloc.dylib on OS X Mavericks as you pointed out), fixed include/pub_tool_redir.h and everything seems to be working good right now. I also created a suppression file named darwin13.supp (already on patch).

The simplest program output (with suppression from darwin13.supp):

==46711== HEAP SUMMARY:
==46711==     in use at exit: 25,030 bytes in 375 blocks
==46711==   total heap usage: 452 allocs, 77 frees, 31,046 bytes allocated
==46711== 
==46711== LEAK SUMMARY:
==46711==    definitely lost: 0 bytes in 0 blocks
==46711==    indirectly lost: 0 bytes in 0 blocks
==46711==      possibly lost: 0 bytes in 0 blocks
==46711==    still reachable: 0 bytes in 0 blocks
==46711==         suppressed: 25,030 bytes in 375 blocks
==46711== 
==46711== For counts of detected and suppressed errors, rerun with: -v
==46711== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 151 from 50)

I changed the testing program to include a malloc(10) without free(). This is the output:

==46697== 10 bytes in 1 blocks are definitely lost in loss record 5 of 77
==46697==    at 0x4711: malloc (vg_replace_malloc.c:295)
==46697==    by 0x100000F5D: main (in ../simple)
==46697== 
==46697== LEAK SUMMARY:
==46697==    definitely lost: 10 bytes in 1 blocks
==46697==    indirectly lost: 0 bytes in 0 blocks
==46697==      possibly lost: 0 bytes in 0 blocks
==46697==    still reachable: 0 bytes in 0 blocks
==46697==         suppressed: 25,030 bytes in 375 blocks
==46697== 
==46697== For counts of detected and suppressed errors, rerun with: -v
==46697== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 151 from 50)

It seems to be working, at least with simple programs.
Can anyone take a better look at the attached patch?

Thanks Diego for the patch. I was able to get valgrind to compile but it doesn't seem like the suppressions were working.

I'm new to this web interface so I don't know how to add attachments.  Here's the script I ran:

http://people.cs.uchicago.edu/~glk/unlinked/mavergrind.sh
(let me know if this is not self-explanatory)

and here's its output:
http://people.cs.uchicago.edu/~glk/unlinked/mavergrind-log.txt

(In reply to comment #7) ...

(In reply to comment #8)
> Thanks Diego for the patch. I was able to get valgrind to compile but it
> doesn't seem like the suppressions were working.
> 
> I'm new to this web interface so I don't know how to add attachments. 
> Here's the script I ran:
> 
> http://people.cs.uchicago.edu/~glk/unlinked/mavergrind.sh
> (let me know if this is not self-explanatory)
> 
> and here's its output:
> http://people.cs.uchicago.edu/~glk/unlinked/mavergrind-log.txt
> 
> (In reply to comment #7) ...

Gordon,

Thanks for trying the patch. I've analyzed your logs and it seems you're not using the darwin13.supp suppressions file when running valgrind. See below how it's used and the output generated for your own test program:

$ valgrind --leak-check=full --tool=memcheck --suppressions=/path/to/darwin13.supp /path/to/mvtest

==63287== HEAP SUMMARY:
==63287==     in use at exit: 25,030 bytes in 375 blocks
==63287==   total heap usage: 452 allocs, 77 frees, 31,046 bytes allocated
==63287== 
==63287== LEAK SUMMARY:
==63287==    definitely lost: 0 bytes in 0 blocks
==63287==    indirectly lost: 0 bytes in 0 blocks
==63287==      possibly lost: 0 bytes in 0 blocks
==63287==    still reachable: 0 bytes in 0 blocks
==63287==         suppressed: 25,030 bytes in 375 blocks
==63287== 
==63287== For counts of detected and suppressed errors, rerun with: -v
==63287== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 151 from 50)

No leaks.

Now testing your own test program with different arguments (forcing a memory leak):

$ valgrind --leak-check=full --tool=memcheck --suppressions=/path/to/darwin13.supp /path/to/mvtest x

==63290== HEAP SUMMARY:
==63290==     in use at exit: 29,126 bytes in 376 blocks
==63290==   total heap usage: 453 allocs, 77 frees, 35,142 bytes allocated
==63290== 
==63290== 4,096 bytes in 1 blocks are definitely lost in loss record 77 of 77
==63290==    at 0x50EA: calloc (vg_replace_malloc.c:622)
==63290==    by 0x100000F23: main (in ../mvtest)
==63290== 
==63290== LEAK SUMMARY:
==63290==    definitely lost: 4,096 bytes in 1 blocks
==63290==    indirectly lost: 0 bytes in 0 blocks
==63290==      possibly lost: 0 bytes in 0 blocks
==63290==    still reachable: 0 bytes in 0 blocks
==63290==         suppressed: 25,030 bytes in 375 blocks
==63290== 
==63290== For counts of detected and suppressed errors, rerun with: -v
==63290== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 151 from 50)

It seems to be working. Can you try again?

Created attachment 83583 [details]
Patch to add support for OS X Mavericks (v3)

Latest patch (darwin13_20131115.patch):

- Added support for F_ADDFILESIGS fcntl flag. No more "UNKNOWN fcntl 61!" output.
- Updated darwin13.supp suppressions file.

Created attachment 83590 [details]
Patch to add support for OS X Mavericks (v4)

Changes:
- Much improved suppressions file (darwin13.supp)

Diego, indeed I incorrectly omitted the suppression file.  I've updated my output log:

http://people.cs.uchicago.edu/~glk/unlinked/mavergrind-log.txt

As you can see, I'm still getting all the "UNKNOWN fcntl 61!" printfs.  That's not consistent with what you get?

Still, I'm getting reasonable output on a few more non-trivial programs, so this is still a big step forward.   Thank you!

I wonder if anything else here is in a position to try this patch?

(In reply to comment #13)
> Diego, indeed I incorrectly omitted the suppression file.  I've updated my
> output log:
> 
> http://people.cs.uchicago.edu/~glk/unlinked/mavergrind-log.txt
> 
> As you can see, I'm still getting all the "UNKNOWN fcntl 61!" printfs. 
> That's not consistent with what you get?
> 

Gordon, I've done all the same steps that your script did and I'm not getting the "UNKNOWN fcntl 61!" output. Can you please double check? This output should not be there anymore.

> Still, I'm getting reasonable output on a few more non-trivial programs, so
> this is still a big step forward.   Thank you!
> 
> I wonder if anything else here is in a position to try this patch?

That's great!
I'm still waiting for some developer to step up and review/commit this patch.

Hello Diego,

I've applied the patch, compiled valgrind and tried it on a trivial program (see below):

[~] > cat test.c
#include <stdlib.h>

int main()
{
        char *s = malloc(sizeof(char) * 100);
        return 0;
}

[~] > valgrind --suppressions=/Users/chutsu/tools/valgrind/darwin13.supp --leak-check=full ./a.out
==27280== Memcheck, a memory error detector
==27280== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27280== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==27280== Command: ./a.out
==27280==
==27280== WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
==27280== WARNING: Expect incorrect results, assertions and crashes.
==27280== WARNING: In particular, Memcheck on 32-bit programs will fail to
==27280== WARNING: detect any errors associated with heap-allocated data.
==27280==
--27280-- ./a.out:
--27280-- dSYM directory is missing; consider using --dsymutil=yes
==27280==
==27280== HEAP SUMMARY:
==27280==     in use at exit: 25,313 bytes in 376 blocks
==27280==   total heap usage: 453 allocs, 77 frees, 31,329 bytes allocated
==27280==
==27280== 100 bytes in 1 blocks are definitely lost in loss record 47 of 77
==27280==    at 0x4711: malloc (vg_replace_malloc.c:295)
==27280==    by 0x100000F5D: main (in ./a.out)
==27280==
==27280== LEAK SUMMARY:
==27280==    definitely lost: 100 bytes in 1 blocks
==27280==    indirectly lost: 0 bytes in 0 blocks
==27280==      possibly lost: 0 bytes in 0 blocks
==27280==    still reachable: 0 bytes in 0 blocks
==27280==         suppressed: 25,213 bytes in 375 blocks
==27280==
==27280== For counts of detected and suppressed errors, rerun with: -v
==27280== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 151 from 50)

For me it does show 1 block of memory lost, which is great. However when I attempt to use it on code that I am currently working on (evolve: https://github.com/chutsu/evolve), it shows some leaks in mac, but not in linux. To replicate run the following: 

git clone https://github.com/chutsu/evolve
bash ./scripts/install_dependencies.sh
cmake .
make
valgrind --suppressions=/Users/chutsu/tools/valgrind/darwin13.supp --leak-check=full --show-leak-kinds=all -v ./bin/gp_tree_validator_tests

output:

==27992== Memcheck, a memory error detector
==27992== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27992== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==27992== Command: ./bin/gp_tree_validator_tests
==27992==
==27992== WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
==27992== WARNING: Expect incorrect results, assertions and crashes.
==27992== WARNING: In particular, Memcheck on 32-bit programs will fail to
==27992== WARNING: detect any errors associated with heap-allocated data.
==27992==
--27992-- Valgrind options:
--27992--    --suppressions=/Users/chutsu/tools/valgrind/darwin13.supp
--27992--    --leak-check=full
--27992--    --show-leak-kinds=all
--27992--    -v
--27992-- Contents of /proc/version:                                                                                                                                                                                                                                 
--27992--   can't open /proc/version
--27992-- Arch and hwcaps: AMD64, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--27992-- Page sizes: currently 4096, max supported 4096
--27992-- Valgrind library directory: /usr/local/lib/valgrind
--27992-- ./bin/gp_tree_validator_tests (rx at 0x100000000, rw at 0x10000e000)
--27992--    reading syms   from primary file (130 751)
--27992--    dSYM directory is missing; consider using --dsymutil=yes
--27992-- /usr/lib/dyld (rx at 0x7fff5fc00000, rw at 0x7fff5fc34000)
--27992--    reading syms   from primary file (6 1183)
--27992-- Scheduler: using generic scheduler lock implementation.
--27992-- Reading suppressions file: /Users/chutsu/tools/valgrind/darwin13.supp
--27992-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
==27992== embedded gdbserver: reading from /var/folders/c4/z8d2nbdd3j11sxqpqr4ynvpw0000gn/T//vgdb-pipe-from-vgdb-to-27992-by-chutsu-on-???
==27992== embedded gdbserver: writing to   /var/folders/c4/z8d2nbdd3j11sxqpqr4ynvpw0000gn/T//vgdb-pipe-to-vgdb-from-27992-by-chutsu-on-???
==27992== embedded gdbserver: shared mem   /var/folders/c4/z8d2nbdd3j11sxqpqr4ynvpw0000gn/T//vgdb-pipe-shared-mem-vgdb-27992-by-chutsu-on-???
==27992==
==27992== TO CONTROL THIS PROCESS USING vgdb (which you probably
==27992== don't want to do, unless you know exactly what you're doing,
==27992== or are doing some strange experiment):
==27992==   /usr/local/lib/valgrind/../../bin/vgdb --pid=27992 ...command...
==27992==
==27992== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==27992==   /path/to/gdb ./bin/gp_tree_validator_tests
==27992== and then give GDB the following command
==27992==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=27992
==27992== --pid is optional if only one valgrind process is running
==27992==
--27992-- REDIR: 0x7fff5fc1b798 (arc4random) redirected to 0x23805fe2e (???)
--27992-- REDIR: 0x7fff5fc21560 (strcmp) redirected to 0x23805fd90 (???)
--27992-- REDIR: 0x7fff5fc1b560 (strlen) redirected to 0x23805fd5f (???)
--27992-- REDIR: 0x7fff5fc1b4c0 (strcpy) redirected to 0x23805fdac (???)
--27992-- REDIR: 0x7fff5fc1ec4f (strcat) redirected to 0x23805fd70 (???)
--27992-- /usr/local/lib/valgrind/vgpreload_core-amd64-darwin.so (rx at 0x1000, rw at 0x2000)
--27992--    reading syms   from primary file (3 31)
--27992--    dSYM= /usr/local/lib/valgrind/vgpreload_core-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_core-amd64-darwin.so
--27992--    reading dwarf3 from dsyms file
--27992-- /usr/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so (rx at 0x4000, rw at 0x8000)
--27992--    reading syms   from primary file (47 244)
--27992--    dSYM= /usr/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-amd64-darwin.so
--27992--    reading dwarf3 from dsyms file
--27992-- /usr/local/Cellar/jansson/2.4/lib/libjansson.4.dylib (rx at 0xc000, rw at 0x14000)
--27992--    reading syms   from primary file (61 73)
--27992-- /usr/lib/libSystem.B.dylib (rx at 0x17000, rw at 0x19000)
--27992--    reading syms   from primary file (31 4)
--27992-- /usr/lib/system/libcache.dylib (rx at 0x1f000, rw at 0x24000)
--27992--    reading syms   from primary file (29 24)
--27992-- /usr/lib/system/libcommonCrypto.dylib (rx at 0x28000, rw at 0x33000)
--27992--    reading syms   from primary file (203 183)
--27992-- /usr/lib/system/libcompiler_rt.dylib (rx at 0x40000, rw at 0x48000)
--27992--    reading syms   from primary file (454 8)
--27992-- /usr/lib/system/libcopyfile.dylib (rx at 0x53000, rw at 0x5b000)
--27992--    reading syms   from primary file (11 28)
--27992-- /usr/lib/system/libcorecrypto.dylib (rx at 0x61000, rw at 0xb0000)
--27992--    reading syms   from primary file (341 430)
--27992-- /usr/lib/system/libdispatch.dylib (rx at 0xc0000, rw at 0xdb000)                                                                                                                                                                                             
--27992--    reading syms   from primary file (176 737)
--27992-- /usr/lib/system/libdyld.dylib (rx at 0xf4000, rw at 0xf8000)
--27992--    reading syms   from primary file (78 96)
--27992-- /usr/lib/system/libkeymgr.dylib (rx at 0xfe000, rw at 0xff000)
--27992--    reading syms   from primary file (12 4)
--27992-- /usr/lib/system/liblaunch.dylib (rx at 0x103000, rw at 0x10b000)
--27992--    reading syms   from primary file (112 1)
--27992-- /usr/lib/system/libmacho.dylib (rx at 0x112000, rw at 0x118000)
--27992--    reading syms   from primary file (86 1)
--27992-- /usr/lib/system/libquarantine.dylib (rx at 0x11d000, rw at 0x120000)
--27992--    reading syms   from primary file (66 32)
--27992-- /usr/lib/system/libremovefile.dylib (rx at 0x125000, rw at 0x127000)
--27992--    reading syms   from primary file (15 4)
--27992-- /usr/lib/system/libsystem_asl.dylib (rx at 0x12c000, rw at 0x13e000)
--27992--    reading syms   from primary file (127 106)
--27992-- /usr/lib/system/libsystem_blocks.dylib (rx at 0x147000, rw at 0x149000)
--27992--    reading syms   from primary file (25 23)
--27992-- /usr/lib/system/libsystem_c.dylib (rx at 0x14d000, rw at 0x1d7000)
--27992--    reading syms   from primary file (1288 783)
--27992-- /usr/lib/system/libsystem_configuration.dylib (rx at 0x202000, rw at 0x205000)
--27992--    reading syms   from primary file (27 58)
--27992-- /usr/lib/system/libsystem_dnssd.dylib (rx at 0x20a000, rw at 0x213000)
--27992--    reading syms   from primary file (68 34)
--27992-- /usr/lib/system/libsystem_info.dylib (rx at 0x219000, rw at 0x241000)
--27992--    reading syms   from primary file (526 526)
--27992-- /usr/lib/system/libsystem_kernel.dylib (rx at 0x256000, rw at 0x273000)
--27992--    reading syms   from primary file (931 2486)
--27992-- /usr/lib/system/libsystem_m.dylib (rx at 0x295000, rw at 0x2c5000)
--27992--    reading syms   from primary file (573 1)
--27992-- /usr/lib/system/libsystem_malloc.dylib (rx at 0x2cf000, rw at 0x2eb000)
--27992--    reading syms   from primary file (102 199)
--27992-- /usr/lib/system/libsystem_network.dylib (rx at 0x2f4000, rw at 0x31c000)
--27992--    reading syms   from primary file (168 1053)
--27992-- /usr/lib/system/libsystem_notify.dylib (rx at 0x337000, rw at 0x341000)
--27992--    reading syms   from primary file (137 48)
--27992-- /usr/lib/system/libsystem_platform.dylib (rx at 0x349000, rw at 0x350000)
--27992--    reading syms   from primary file (114 1463)
--27992-- /usr/lib/system/libsystem_pthread.dylib (rx at 0x362000, rw at 0x36a000)
--27992--    reading syms   from primary file (137 54)
--27992-- /usr/lib/system/libsystem_sandbox.dylib (rx at 0x375000, rw at 0x377000)
--27992--    reading syms   from primary file (61 8)
--27992-- /usr/lib/system/libsystem_stats.dylib (rx at 0x37b000, rw at 0x380000)
--27992--    reading syms   from primary file (20 42)
--27992-- /usr/lib/system/libunc.dylib (rx at 0x386000, rw at 0x388000)
--27992--    reading syms   from primary file (31 4)
--27992-- /usr/lib/system/libunwind.dylib (rx at 0x38d000, rw at 0x393000)
--27992--    reading syms   from primary file (102 52)
--27992-- /usr/lib/system/libxpc.dylib (rx at 0x399000, rw at 0x3be000)
--27992--    reading syms   from primary file (349 818)
--27992-- /usr/lib/libobjc.A.dylib (rx at 0x3da000, rw at 0x588000)
--27992--    reading syms   from primary file (342 735)
--27992-- /usr/lib/libauto.dylib (rx at 0x5a8000, rw at 0x5eb000)
--27992--    reading syms   from primary file (68 742)
--27992-- /usr/lib/libc++abi.dylib (rx at 0x602000, rw at 0x62c000)
--27992--    reading syms   from primary file (322 178)
--27992-- /usr/lib/libc++.1.dylib (rx at 0x639000, rw at 0x68c000)
--27992--    reading syms   from primary file (2070 1507)
--27992-- /usr/lib/libDiagnosticMessagesClient.dylib (rx at 0x6e7000, rw at 0x6e9000)
--27992--    reading syms   from primary file (21 14)
--27992-- REDIR: 0x2e0266 (malloc) redirected to 0x4690 (malloc)
--27992-- REDIR: 0x2dec43 (malloc_default_zone) redirected to 0x62f0 (malloc_default_zone)
--27992-- REDIR: 0x2df835 (malloc_zone_malloc) redirected to 0x4a00 (malloc_zone_malloc)
--27992-- REDIR: 0x2dfef8 (free) redirected to 0x4c40 (free)
--27992-- REDIR: 0x2dfb26 (malloc_zone_calloc) redirected to 0x52e0 (malloc_zone_calloc)
--27992-- REDIR: 0x2dfd02 (malloc_zone_from_ptr) redirected to 0x6310 (malloc_zone_from_ptr)
--27992-- REDIR: 0x2e02ad (calloc) redirected to 0x5020 (calloc)
==27992==
==27992== HEAP SUMMARY:
==27992==     in use at exit: 29,465 bytes in 379 blocks
==27992==   total heap usage: 823 allocs, 444 frees, 55,001 bytes allocated
==27992==
==27992== Searching for pointers to 379 not-freed blocks
==27992== Checked 8,988,240 bytes
==27992==
==27992== 32 bytes in 1 blocks are still reachable in loss record 31 of 81
==27992==    at 0x4711: malloc (vg_replace_malloc.c:295)
==27992==    by 0x16EB50: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x16BC83: __rv_alloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x16C1C9: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x193949: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA37A: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA74F: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x191BC9: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x18FA0F: printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x10000181F: test_print_node (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001E33: print_program (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001DDA: setup (in ./bin/gp_tree_validator_tests)
==27992==
==27992== 36 bytes in 1 blocks are still reachable in loss record 34 of 81
==27992==    at 0x4711: malloc (vg_replace_malloc.c:295)
==27992==    by 0x16EB50: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x16F345: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x16BF76: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x193949: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA37A: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA74F: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x191BC9: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x18FA0F: printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x10000181F: test_print_node (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001E33: print_program (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001DDA: setup (in ./bin/gp_tree_validator_tests)
==27992==
==27992== 80 bytes in 1 blocks are still reachable in loss record 49 of 81
==27992==    at 0x4711: malloc (vg_replace_malloc.c:295)
==27992==    by 0x16EAA6: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x16F345: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x16BF76: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x193949: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA37A: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA74F: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x191BC9: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x18FA0F: printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x10000181F: test_print_node (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001E33: print_program (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001DDA: setup (in ./bin/gp_tree_validator_tests)
==27992==
==27992== 4,096 bytes in 1 blocks are still reachable in loss record 81 of 81
==27992==    at 0x4711: malloc (vg_replace_malloc.c:295)
==27992==    by 0x18C8F5: __smakebuf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1A12B7: __swsetup (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA1F8: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x1BA74F: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x191BC9: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x18FA0F: printf (in /usr/lib/system/libsystem_c.dylib)
==27992==    by 0x100001DF5: print_program (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001DDA: setup (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001AC4: test_suite (in ./bin/gp_tree_validator_tests)
==27992==    by 0x100001C83: main (in ./bin/gp_tree_validator_tests)
==27992==
==27992== LEAK SUMMARY:
==27992==    definitely lost: 0 bytes in 0 blocks
==27992==    indirectly lost: 0 bytes in 0 blocks
==27992==      possibly lost: 0 bytes in 0 blocks
==27992==    still reachable: 4,244 bytes in 4 blocks
==27992==         suppressed: 25,221 bytes in 375 blocks
==27992==
==27992== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 560 from 84)
--27992--
--27992-- used_suppression:     34 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:791 suppressed: 13,656 bytes in 252 blocks
--27992-- used_suppression:      1 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:741 suppressed: 2,064 bytes in 1 blocks
--27992-- used_suppression:     15 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:802 suppressed: 7,037 bytes in 72 blocks
--27992-- used_suppression:      3 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:750 suppressed: 1,647 bytes in 3 blocks
--27992-- used_suppression:      5 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:813 suppressed: 1,367 bytes in 23 blocks
--27992-- used_suppression:     10 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:823 suppressed: 609 bytes in 15 blocks
--27992-- used_suppression:      6 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:781 suppressed: 176 bytes in 6 blocks
--27992-- used_suppression:      1 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:759 suppressed: 16 bytes in 1 blocks
--27992-- used_suppression:      2 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:833 suppressed: 16 bytes in 2 blocks
--27992-- used_suppression:    226 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:900
--27992-- used_suppression:    153 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:893
--27992-- used_suppression:    148 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:907
--27992-- used_suppression:      1 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:852
--27992-- used_suppression:     10 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:870
--27992-- used_suppression:      2 <insert_a_suppression_name_here> /usr/local/lib/valgrind/default.supp:843
==27992==
==27992== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 560 from 84)

Diego - my script starts by blowing away the trunk and the patch, and all the commands and output are WYSIWYG in http://people.cs.uchicago.edu/~glk/unlinked/mavergrind-log.txt .  Is the http://bugsfiles.kde.org/attachment.cgi?id=83590 URL correct for your patch, and does your cksum match mine "3947541149 13404"?  Or maybe I'm using "patch -p0" wrong?

Chris - I can't tell from the output - have you found darwin/linux differences that are NOT related the printf family of functions?

Gordon - At the moment it seems to be just simple printf statements that are problematic, I have only just learnt how to use a supression file, and have created my own to suppress these errors at the moment, so far I have the following:

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:__smakebuf
   fun:__swsetup
   fun:__v2printf
   fun:__xvprintf
   fun:vfprintf_l
   fun:printf
}
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:__Balloc_D2A
   fun:__rv_alloc_D2A
   fun:__dtoa
   fun:__vfprintf
   fun:__v2printf
   fun:__xvprintf
   fun:vfprintf_l
   fun:printf
}
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:__Balloc_D2A
   fun:__d2b_D2A
   fun:__dtoa
   fun:__vfprintf
   fun:__v2printf
   fun:__xvprintf
   fun:vfprintf_l
   fun:printf
}

(In reply to comment #15)
> Hello Diego,
> 
> I've applied the patch, compiled valgrind and tried it on a trivial program
> (see below):
> 
> [~] > cat test.c
> #include <stdlib.h>
> 
> int main()
> {
>         char *s = malloc(sizeof(char) * 100);
>         return 0;
> }
> 
> [~] > valgrind --suppressions=/Users/chutsu/tools/valgrind/darwin13.supp
> --leak-check=full ./a.out
> ==27280== Memcheck, a memory error detector
> ==27280== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==27280== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==27280== Command: ./a.out
> ==27280==
> ==27280== WARNING: Support on MacOS 10.8/10.9 is experimental and mostly
> broken.
> ==27280== WARNING: Expect incorrect results, assertions and crashes.
> ==27280== WARNING: In particular, Memcheck on 32-bit programs will fail to
> ==27280== WARNING: detect any errors associated with heap-allocated data.
> ==27280==
> --27280-- ./a.out:
> --27280-- dSYM directory is missing; consider using --dsymutil=yes
> ==27280==
> ==27280== HEAP SUMMARY:
> ==27280==     in use at exit: 25,313 bytes in 376 blocks
> ==27280==   total heap usage: 453 allocs, 77 frees, 31,329 bytes allocated
> ==27280==
> ==27280== 100 bytes in 1 blocks are definitely lost in loss record 47 of 77
> ==27280==    at 0x4711: malloc (vg_replace_malloc.c:295)
> ==27280==    by 0x100000F5D: main (in ./a.out)
> ==27280==
> ==27280== LEAK SUMMARY:
> ==27280==    definitely lost: 100 bytes in 1 blocks
> ==27280==    indirectly lost: 0 bytes in 0 blocks
> ==27280==      possibly lost: 0 bytes in 0 blocks
> ==27280==    still reachable: 0 bytes in 0 blocks
> ==27280==         suppressed: 25,213 bytes in 375 blocks
> ==27280==
> ==27280== For counts of detected and suppressed errors, rerun with: -v
> ==27280== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 151 from 50)
> 
> For me it does show 1 block of memory lost, which is great. However when I
> attempt to use it on code that I am currently working on (evolve:
> https://github.com/chutsu/evolve), it shows some leaks in mac, but not in
> linux. 

Hi Chris,

The provided darwin13.supp suppressions file if far from complete and probably needs more love. From your output it seems that there's some allocation on the printf family of functions that still reachable. You can try it again adding the following to the suppressions file:

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:?alloc
   ...
   fun:printf
}

There's more info on the valgrind docs about creating these entries.

Just thought I'd chime in that I too was able to get valgrind to build on my OSX 10.9 system (note: title of this bug report incorrectly uses "OSX 1.9"). For me, I grabbed the valgrind source from svn, applied the patch, downloaded/built automake-1.14 , created a symlink for my /usr/include (otherwise I got an error in the build), and the build finished.  A simple test seemed to confirm that it was working. I.e.:

svn co svn://svn.valgrind.org/valgrind/trunk valgrind
- insert the patch into the valgrind root dir and:
patch -p0 <darwin13_20131115_2.patch
- install automake-1.14
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/    /usr/include

  ./autogen.sh
  ./configure --prefix=...
  make
  sudo make install

--> /usr/local/bin:
-rwxr-xr-x  1 root     admin     41106 Dec 19 11:38 callgrind_annotate*
-rwxr-xr-x  1 root     admin     11527 Dec 19 11:38 callgrind_control*
-rwxr-xr-x  1 root     admin     32174 Dec 19 11:38 cg_annotate*
-rwxr-xr-x  1 root     admin     10422 Dec 19 11:38 cg_diff*
-rwxr-xr-x  1 root     admin     29172 Dec 19 11:38 cg_merge*
-rwxr-xr-x  1 root     admin     24216 Dec 19 11:38 ms_print*
-rwxr-xr-x  1 root     admin     19700 Dec 19 11:38 valgrind*
-rwxr-xr-x  1 root     admin     33568 Dec 19 11:38 valgrind-di-server*
-rwxr-xr-x  1 root     admin     14304 Dec 19 11:38 valgrind-listener*
-rwxr-xr-x  1 root     admin     34752 Dec 19 11:38 vgdb*

--------------  simple test:
~/dev/valgrind-play$ cat a.c
#include <stdlib.h>
#include <stdio.h>

void f(void)
{
  int* x = malloc(10 * sizeof(int));
  x[10] = 0;        // problem 1: heap block overrun
}                    // problem 2: memory leak -- x not freed

int main(void)
{
  int i;
  scanf("%d", &i);     # insert this to also test with OSX's 'leak' which needs a running process
  f();
  return 0;
}

~/dev/valgrind-play$ valgrind --leak-check=yes a.out
==45524== Memcheck, a memory error detector
==45524== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==45524== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==45524== Command: a.out
==45524== 
==45524== WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
==45524== WARNING: Expect incorrect results, assertions and crashes.
==45524== WARNING: In particular, Memcheck on 32-bit programs will fail to
==45524== WARNING: detect any errors associated with heap-allocated data.
==45524== 
--45524-- ./a.out:
--45524-- dSYM directory is missing; consider using --dsymutil=yes
1
==45524== Invalid write of size 4
==45524==    at 0x100000F1F: f (in ./a.out)
==45524==    by 0x100000F58: main (in ./a.out)
==45524==  Address 0x100013428 is 0 bytes after a block of size 40 alloc'd
==45524==    at 0x4711: malloc (vg_replace_malloc.c:295)
==45524==    by 0x100000F16: f (in ./a.out)
==45524==    by 0x100000F58: main (in ./a.out)
==45524== 
==45524== 
==45524== HEAP SUMMARY:
==45524==     in use at exit: 29,632 bytes in 377 blocks
==45524==   total heap usage: 454 allocs, 77 frees, 35,648 bytes allocated
==45524== 
==45524== 40 bytes in 1 blocks are definitely lost in loss record 32 of 78
==45524==    at 0x4711: malloc (vg_replace_malloc.c:295)
==45524==    by 0x100000F16: f (in ./a.out)
==45524==    by 0x100000F58: main (in ./a.out)
==45524== 
==45524== LEAK SUMMARY:
==45524==    definitely lost: 40 bytes in 1 blocks
==45524==    indirectly lost: 0 bytes in 0 blocks
==45524==      possibly lost: 0 bytes in 0 blocks
==45524==    still reachable: 4,096 bytes in 1 blocks
==45524==         suppressed: 25,496 bytes in 375 blocks
==45524== Reachable blocks (those to which a pointer was found) are not shown.
==45524== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==45524== 
==45524== For counts of detected and suppressed errors, rerun with: -v
==45524== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 151 from 50)

I tried building the latest valgrind (r13783) with the attached patch applied without success. What are you doing that I'm not?

Here's the output:

$ clang -g -O0 a.c

$ which valgrind
/opt/local/bin/valgrind

$ ls -l /opt/local/bin/valgrind
-rwxr-xr-x  1 root  admin  19320 29 Jan 22:28 /opt/local/bin/valgrind

$ valgrind --version
valgrind-3.10.0.SVN

$ valgrind --leak-check=yes ./a.out
==2691== Memcheck, a memory error detector
==2691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2691== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==2691== Command: ./a.out
==2691==
==2691== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==2691== WARNING: Expect incorrect results, assertions and crashes.
==2691== WARNING: In particular, Memcheck on 32-bit programs will fail to
==2691== WARNING: detect any errors associated with heap-allocated data.
==2691==
==2691== Syscall param fcntl(F_ADDSIGS, fsigs->fs_blob_start) points to unaddressable byte(s)
==2691==    at 0x7FFF5FC23A6E: __fcntl (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC106AB: ImageLoaderMachO::loadCodeSignature(linkedit_data_command const*, int, unsigned long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC156B3: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0F9FF: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0375B: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC085D4: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC08290: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC08178: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC079C5: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC03425: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC031BA: dyld::load(char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC07336: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) (in /usr/lib/dyld)
==2691==  Address 0x5b900 is not stack'd, malloc'd or (recently) free'd
==2691==
eq_SyscallStatus:
  {78 0 43}
  {78 0 40}

valgrind: m_syswrap/syswrap-main.c:381 (Bool eq_SyscallStatus(SyscallStatus *, SyscallStatus *)): the 'impossible' happened.
==2691==    at 0x2380439CB: ???
==2691==    by 0x238043978: ???
==2691==    by 0x2380C1A83: ???
==2691==    by 0x2380C117D: ???
==2691==    by 0x2380BF522: ???
==2691==    by 0x2380BD54D: ???
==2691==    by 0x2380CF400: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==2691==    at 0x25C966: _kernelrpc_mach_vm_map_trap (in /usr/lib/system/libsystem_kernel.dylib)
==2691==    by 0x2C6F6F: allocate_pages (in /usr/lib/system/libsystem_malloc.dylib)
==2691==    by 0x2C6A11: create_scalable_zone (in /usr/lib/system/libsystem_malloc.dylib)
==2691==    by 0x2D43ED: _malloc_initialize (in /usr/lib/system/libsystem_malloc.dylib)
==2691==    by 0x2D527D: malloc (in /usr/lib/system/libsystem_malloc.dylib)
==2691==    by 0x7FFF5FC12D4F: malloc (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC1A3BD: operator new(unsigned long) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC090EC: std::__1::__split_buffer<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*), std::__1::allocator<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)>&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC08A44: std::__1::vector<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*), std::__1::allocator<char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)> >::insert(std::__1::__wrap_iter<char const* (* const*)(dyld_image_states, unsigned int, dyld_image_info const*)>, char const* (* const&)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0426B: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==2691==    by 0xEB8F0: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==2691==    by 0xEB6B1: _dyld_initializer (in /usr/lib/system/libdyld.dylib)
==2691==    by 0xDA9D: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==2691==    by 0x7FFF5FC11C2D: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC11DB9: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0EA61: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0E9EA: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0E8F5: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC021B6: dyld::initializeMainExecutable() (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0555F: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0127A: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==2691==    by 0x7FFF5FC0105D: _dyld_start (in /usr/lib/dyld)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Daniel,

You definitely have not applied the patch correctly. The output of your valgrind is different from the output of the version with the applied patch. The correct version shows:

"WARNING: Support on MacOS 10.8/10.9 is experimental and mostly"

Yours is:

"WARNING: Support on MacOS 10.8 is experimental and mostly broken."

You're right, which is very bizarre. I did svn update, make distclean, cat ~/Downloads/valgrind.patch |patch -p0, which succeded with some offsets, and built just fine. When running svn diff I can indeed see the change to "WARNING: Support on MacOS 10.8/10.9 is experimental and mostly", but when running it, it's still says just 10.8. Should probably checkout the repository again and try from scratch, but I'm on a very broken Hotel wifi so I have to get back to you later.

Actually the following helped:

make distclean
find . -type f -exec svn revert {} +
find . -name '*.orig*' -exec rm {} +
checking that svn status is clean
cat valgrind.patch | patch -p0
find . -name '*orig*' -exec rm {} +

I wonder if autohell picked up the orig files instead for some obscure reason, the patch was indeed applied when I first tested. Anyways, now it builds, and when running it says:
"==46270== WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken."

It does however hang on the test application that was mentioned some comment back with the same parameters. When running it with my unit-test (which calls for a leak check between each function) it does however not hang, but the report seems broken, the output is as follows: http://3df2d36e9bad048c.paste.se/

The test is clean on Linux, and is clean on OS X before Mountain Lion so I expect this to be a valgrind-related problem, correct?

I tried the steps above, including applying the patch, and I am not able to compile valgrind.  

m_syscall.c:574:1: error: unknown type name ‘__private_extern__’
 __private_extern__ UWord 
 ^
m_syscall.c:575:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘do_syscall_unix_WRK’
 do_syscall_unix_WRK ( UWord a1, UWord a2, UWord a3, /* rdi, rsi, rdx */
 ^
m_syscall.c:598:1: error: unknown type name ‘__private_extern__’
 __private_extern__ UWord 
 ^
m_syscall.c:599:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘do_syscall_mach_WRK’
 do_syscall_mach_WRK ( UWord a1, UWord a2, UWord a3, /* rdi, rsi, rdx */
 ^
m_syscall.c: In function ‘vgPlain_do_syscall’:
m_syscall.c:775:10: warning: implicit declaration of function ‘do_syscall_unix_WRK’ [-Wimplicit-function-declaration]
          wLO = do_syscall_unix_WRK(a1,a2,a3,a4,a5,a6,a7,a8,
          ^
m_syscall.c:780:10: warning: implicit declaration of function ‘do_syscall_mach_WRK’ [-Wimplicit-function-declaration]
          wLO = do_syscall_mach_WRK(a1,a2,a3,a4,a5,a6,a7,a8, 
          ^
make[3]: *** [libcoregrind_amd64_darwin_a-m_syscall.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I've tried this patch and it works fine for me.

$ uname -a
Darwin Macintosh-4.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64 i386 MacBookAir5,2 Darwin

Furthermore homebrew packaged valgrind with this patch a month ago successfully.
So it likes safe to apply.

I've tried this patch and it works fine for me.

$ uname -a
Darwin Macintosh-4.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64 i386 MacBookAir5,2 Darwin

Furthermore homebrew packaged valgrind with this patch a month ago successfully.
So it looks safe to apply.

Created attachment 85889 [details]
patches for darwin13/macosx 10.9

Hi there,
I made a series of patches for Darwin 10.9, adding new syscalls or renaming some anonymous ones, and a few other improvements. I believe it works much better with these.

They are to be applied on current SVN trunk, after applying Diego Giagio's patch.

Could you try them and validate it's working better with them ?

Thanks,

---
You can find them on my homebrew branch there for the git friendly people (it's a messy and unofficial import, I forgot to change emails in valgind import, so fork it at your own risk please) : 
https://github.com/fredericgermain/valgrind/tree/homebrew

Hey Frederic,

I tried applying your patches but having trouble

patch -p0 < 0001-adding-support-for-loads-of-new-syscall-in-darwin-10.patch 
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From ce05c1ebd68b20f826b53f6034b9dc5001f3cefd Mon Sep 17 00:00:00 2001
|From: Frederic Germain <frederic.germain@gmail.com>
|Date: Thu, 27 Mar 2014 16:19:18 +0100
|Subject: [PATCH 1/6] adding support for loads of new syscall in darwin 10.9
|
|---
| coregrind/m_syswrap/priv_syswrap-darwin.h |  48 +++-
| coregrind/m_syswrap/syswrap-darwin.c      | 411 ++++++++++++++++++++++++++----
| coregrind/pub_core_threadstate.h          |   4 +
| include/vki/vki-darwin.h                  |   1 +
| include/vki/vki-scnums-darwin.h           |  54 ++++
| 5 files changed, 458 insertions(+), 60 deletions(-)
|
|diff --git a/coregrind/m_syswrap/priv_syswrap-darwin.h b/coregrind/m_syswrap/priv_syswrap-darwin.h
|index 9a1fa80..6260d69 100644
|--- a/coregrind/m_syswrap/priv_syswrap-darwin.h
|+++ b/coregrind/m_syswrap/priv_syswrap-darwin.h
--------------------------

You want "-p1" not "-p0" as you need to strip off the leading a/ prefix that git has added.

Thanks Tom.

Okay, the build made it farther but still got stuck

svn update
make distclean
find . -type f -exec svn revert {} +
find . -name '*.orig*' -exec rm {} +
cat valgrind.patch | patch -p0
patch -p1 < 0001-adding-support-for-loads-of-new-syscall-in-darwin-10.patch 
patch -p1 < 0002-thread_state_from_vex-adding-support-for-x86_THREAD_.patch 
patch -p1 < 0003-darwin-remove-warnings-in-logs-related-to-Char-HChar.patch 
patch -p1 < 0004-wqthread_hijack-fix-magic_delta-on-darwin-10.9.patch 
patch -p1 < 0005-darwin-try-to-improve-support-for-mach_msg-on-extern.patch 
patch -p1 < 0006-aspacem_minAddr-is-0x1000-on-darwin-x64.patch 
./autogen.sh 
./configure --prefix=/usr/local
make

 (excerpt from where it got stuck)

mv -f .deps/libcoregrind_amd64_darwin_a-m_stacktrace.Tpo .deps/libcoregrind_amd64_darwin_a-m_stacktrace.Po
gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1 -DVGPV_amd64_darwin_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"amd64-darwin\""   -arch x86_64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -mmacosx-version-min=10.5 -fno-stack-protector  -Wno-long-long  -Wwrite-strings -fno-stack-protector -MT libcoregrind_amd64_darwin_a-m_syscall.o -MD -MP -MF .deps/libcoregrind_amd64_darwin_a-m_syscall.Tpo -c -o libcoregrind_amd64_darwin_a-m_syscall.o `test -f 'm_syscall.c' || echo './'`m_syscall.c
m_syscall.c:574:1: error: unknown type name ‘__private_extern__’
 __private_extern__ UWord  
 ^
m_syscall.c:575:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘do_syscall_unix_WRK’
 do_syscall_unix_WRK ( UWord a1, UWord a2, UWord a3, /* rdi, rsi, rdx */
 ^
m_syscall.c:598:1: error: unknown type name ‘__private_extern__’
 __private_extern__ UWord 
 ^
m_syscall.c:599:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘do_syscall_mach_WRK’
 do_syscall_mach_WRK ( UWord a1, UWord a2, UWord a3, /* rdi, rsi, rdx */
 ^
m_syscall.c: In function ‘vgPlain_do_syscall’:
m_syscall.c:775:10: warning: implicit declaration of function ‘do_syscall_unix_WRK’ [-Wimplicit-function-declaration]
          wLO = do_syscall_unix_WRK(a1,a2,a3,a4,a5,a6,a7,a8,
          ^
m_syscall.c:780:10: warning: implicit declaration of function ‘do_syscall_mach_WRK’ [-Wimplicit-function-declaration]
          wLO = do_syscall_mach_WRK(a1,a2,a3,a4,a5,a6,a7,a8, 
          ^
make[3]: *** [libcoregrind_amd64_darwin_a-m_syscall.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I was able to compile and am using valgrind with these patches, but my configure line was slightly different than yours

./configure CC=clang CXX=clang++

Hi all,
Sorry, it seems I'm not registered to this bug's notifications...
cphillips, I couldn't get your problem. I checked I have exactly the same gcc arguments when compiling m_syscall.c.

my gcc version :
> gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

And autoconf tools are from homebrew.

I took the sources from git, but probably we end up with exactly the same sources :

git clone https://github.com/fredericgermain/valgrind.git
cd valgrind
## go to homebrew branch, before the patch from Diego/Fred
git checkout 759ea7abe1b3c62
## we are on « svn » branch with for git, get VEX submodule
git submodule init
git submodule update
cat valgrind.patch | patch -p0
patch -p1 < 0001-adding-support-for-loads-of-new-syscall-in-darwin-10.patch 
patch -p1 < 0002-thread_state_from_vex-adding-support-for-x86_THREAD_.patch 
patch -p1 < 0003-darwin-remove-warnings-in-logs-related-to-Char-HChar.patch 
patch -p1 < 0004-wqthread_hijack-fix-magic_delta-on-darwin-10.9.patch 
patch -p1 < 0005-darwin-try-to-improve-support-for-mach_msg-on-extern.patch 
patch -p1 < 0006-aspacem_minAddr-is-0x1000-on-darwin-x64.patch 
./autogen.sh 
./configure --prefix=/usr/local
make

I would suspect your gcc version... Could you check it or use clang the way waTeim use it ?

With reference to https://trac.macports.org/ticket/41048 (which indicates that MacPorts' valgrind-devel port will be updated once these patches are applied upstream in valgrind), it would be great if this patch / these patches (which is the current / recommended? attachment 83590 [details] or attachment 85889 [details] … or both?) could be applied in the subversion repository, since at that point it will be possible to update the MacPorts valgrind-devel port, and have it working on Mac OS 10.9!

Is there any outstanding question about them which is preventing this from happening? Valgrind's an extremely useful tool on Mac OS, and I for one would greatly welcome its resurrection in MacPorts on the two most recent versions of that OS!

It would appear that valgrind builds (and somewhat works) on 10.9 (thanks to this bug and the patches submitted inline), when using home-brew.  I would like to pile on asking that 10.9 support is re-added to mainline valgrind.

for now, brew install valgrind "just works"

The 32 bit heap problems are a total headache for me (because I'm trying to use valgrind to check programs in the iOS simulator).  I was able to get this working for the iOS 6 simulator with a small fix to VEX on 10.7.

I would like to integrate these patches into the mainline, but I don't
have a 10.9 box to test on.  And I don't really want to land this stuff
without being able to test it.  Also, it may be necessary to fix up the
heap interceptors a bit, which definitely can't do without access to
hardware.

10.9 run well in VirtualBox nowadays, and from 10.9 the price tag is $0, so the cost is down to the time it takes to setup such a virtual machine. I don't see what real hardware has to offer in addition to that?

What is it going to take to get you a 10.9 box?  Perhaps we could crowd-tilt the valgrind team a mac mini?

(In reply to comment #35)
> I would like to integrate these patches into the mainline, but I don't
> have a 10.9 box to test on.

I can see about getting you remote access to my iMac if you want.  I generally run the latest Beta OS on it though.

(In reply to comment #37)
> What is it going to take to get you a 10.9 box?  Perhaps we could crowd-tilt
> the valgrind team a mac mini?

I could help some $ on that.  Referbs we could get pretty cheap.

Additionally, if you could point me at where I could get started learning what I need to learn to help with the heap interceptors, I would love to do this.  I spent all weekend playing with the source of the darwin x86 syswrap, trying to understand why it appears that the arguments to wqthread_hijack are seriously wrong, and I'd like to go deeper.

Oh, looks like sys wrap is missing syscall 410, appears to get hit when using libdispatch.  Here's a sample program that will reproduce the issue:

----
#include <stdio.h>
#include <stdlib.h>
#include <dispatch/dispatch.h>

void doPrintString(const char* str);

int main(int argc, char** argv) {
  dispatch_queue_t main_queue = dispatch_get_main_queue();
  dispatch_queue_t my_queue = dispatch_queue_create("MyQueue", NULL);
  dispatch_async(my_queue, ^{ 
      doPrintString("Hello, World!\n"); 
      dispatch_async(main_queue, ^{ exit(0); }); 
    });
  dispatch_main();

  return 0;
}

void doPrintString(const char* str) {
  printf("%s", str);
}
----

Diego, Frederic: I have been trying out your patch sets today and have
been able to run some GUI apps (Calculator, TextEdit) on 10.9 as a
result.  Thanks for them.

Are these the latest versions of your patches, or are there any
updates?

A new version of XCode (Version 5.1.1 (5B1008)) breaks the build, so there is another patch for that :

https://github.com/fredericgermain/valgrind/commit/fa0bf3980aefb58d513997dc76dc1911c4ddf9e4

I don't really know what the -mno-dynamic-no-pic option does, but it works fine without it :)

> Are these the latest versions of your patches, or are there any
> updates?

Yes. Mine is the latest version.

Frederic, what problem does
0006-aspacem_minAddr-is-0x1000-on-darwin-x64.patch solve?

Nothing bad, there was a warning when we launched a program during init with the old value, like some address were being accessed between 0x1000 and the previous value
It seems I 0x1000 is really the aspacem_minAddr, so it removed the warnings.

(In reply to comment #45)
> Frederic, what problem does
> 0006-aspacem_minAddr-is-0x1000-on-darwin-x64.patch solve?

(In reply to comment #46)
> Nothing bad, there was a warning when we launched a program during init with
> the old value, like some address were being accessed between 0x1000 and the
> previous value
> It seems I 0x1000 is really the aspacem_minAddr, so it removed the warnings.
On Darwin 64bits, it seems the lowest address is 4GB since the Darwin branch
was merged in the tree.
No idea why it as initially set to 4GB.
However, would that change not give a problem on previous Darwin versions ?
What is the exact warning that is given with the 4GB limit, and which is not
given with the 0x1000 limit ?

> 
> (In reply to comment #45)
> > Frederic, what problem does
> > 0006-aspacem_minAddr-is-0x1000-on-darwin-x64.patch solve?

(In reply to comment #12)
> Created attachment 83590 [details]
> Patch to add support for OS X Mavericks (v4)

Committed, with very minor changes to make it also build on 10.8,
r14055 and r14056.  Thanks for the patch.

(In reply to comment #27)
> Created attachment 85889 [details]
> patches for darwin13/macosx 10.9

Committed:

0001-adding-support-for-loads-of-new-syscall-in-darwin-10
  r14058, r14058

0002-thread_state_from_vex-adding-support-for-x86_THREAD_
  r14059

0003-darwin-remove-warnings-in-logs-related-to-Char-HChar
  r14060

0004-wqthread_hijack-fix-magic_delta-on-darwin-10.9
  r14061

0005-darwin-try-to-improve-support-for-mach_msg-on-extern
  r14062

I didn't commit 0006-aspacem_minAddr-is-0x1000-on-darwin-x64.  I
remember vaguely that aspacem_minAddr is set to 4GB on amd64-darwin
for some reason, and setting it lower breaks something.  But I don't
remember any details unfortunately.

Thanks for the patches, and sorry to be so slow committing them.

Thanks everyone for your work to support this.
What are the next steps to progress, does it require more in developer time or testing?

I'm not in a position to assist from a code perspective, but happy to assist testing once I have a build environment setup.

It builds and works fairly well now on 10.9, for both 32- and 64-bit processes.
Closing.

I still can't get it to work on my OSX 10.9.x.

--->  Computing dependencies for valgrind
--->  Fetching distfiles for valgrind
Error: valgrind 3.9.0 is only compatible with Mac OS X 10.5, 10.6, 10.7 and 10.8
Error: org.macports.fetch for port valgrind returned: incompatible Mac OS X version
Please see the log file for port valgrind for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_valgrind/valgrind/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port valgrind failed

(In reply to Lee Wei from comment #52)
> I still can't get it to work on my OSX 10.9.x.

That looks to me as if it is simply that the Portfile needs to be updated in MacPorts to allow MacPorts to /attempt/ to build valgrind on OS 10.9. That will be a simple fix to that file. I suggest filing a ticket in Macports' trac to cover that downstream fix, now that upstream (here!) is fixed.

Yeah .. try checking it out directly from svn://svn.valgrind.org/valgrind/trunk
and see if it works.

Please see https://trac.macports.org/ticket/44557 for the request to update the MacPorts port.