Valgrind for OSX 10.7 (Lion) status update

jseward

8 responses

Various sets of fixes have been committed for Valgrind on Lion.  It now works well enough to run 64 bit Firefox builds and get sane results.  32 bit builds run too, but appear to hang, for threading related reasons I cannot figure out, despite quite some investigative effort.

There may be some false positives from Memcheck as a result of kludged-up syscall wrappers for some new syscalls that are 10.7-specific.  Let me know if you see errors which you think are obviously bogus.

Feedback is welcomed.  If you’re developing on Mac and have migrated to 10.7, I’d be interested to hear if it works for you. If you’re still on 10.6, I’d be interested to hear if I broke anything :-)  Btw, 10.5 support is pretty much dropped now — is anybody still using 10.5 for development?

The tracking bug report is valgrind bug 275168.

Quick reminder of how to check out and build:

  svn co svn://svn.valgrind.org/valgrind/trunk
  cd trunk
  ./autogen.sh
  ./configure --prefix=`pwd`/Inst
  make -j2
  make -j2 install

8 responses

  1. bc wrote on :

    My local laptop is still 10.5, but it is reaching eol anyway. Gecko 1.9.2 requires Mac OS X 10.5 to build but can live with older valgrinds I suppose.

    1. jseward wrote on :

      3.6.1 should work fine on 10.5. btw, I’m not saying that current trunk doesn’t work on 10.5 — just that I haven’t verified that it does, and (unless requested otherwise) don’t plan to spend time doing so.

  2. Florian Quèze wrote on :

    I also still use 10.5.

  3. dc wrote on :

    I just checked out the trunk and am running it on 10.7.1. It appears to work fine on some code in VTK (http://vtk.org/), which is a large-ish toolkit.

    However, is the gdb/vgdb stuff supposed to work on OS X? When I try to attach to valgrind’s gdb-server, I get:

    (gdb) target remote | /usr/local/lib/valgrind/../../bin/vgdb –pid=11722
    | /usr/local/lib/valgrind/../../bin/vgdb –pid=11722: No such file or directory
    (gdb) target remote | /usr/local/bin/vgdb –pid=11722
    | /usr/local/bin/vgdb –pid=11722: Undefined error: 0

    1. jseward wrote on :

      The gdb-server stuff probably doesn’t work on OS X at present, sorry.

  4. Bob wrote on :

    I’m only using for a hello world project right now, but thought you’d like to know I’m on OS X 10.7.1 and can compile valgrind from svn trunk and run it successfully. Let me know if you want more info, regards, Bob.

  5. Kalileo wrote on :

    First of all, thanks for your work on this useful tool!

    Some feedback from testing this version: OS X 10.7.2:

    it compiled without problems, but when trying to use it for a Qt Application valgrind committed suicide:

    ==15667== Memcheck, a memory error detector
    ==15667== Copyright (C) 2002-2011, and GNU GPL’d, by Julian Seward et al.
    ==15667== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
    ==15667== Command: /Path/to/application
    …
    …
    vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8 0x6A
    ==15667== valgrind: Unrecognised instruction at address 0x25e6c0b.
    ==15667== at 0x25E6C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E49E0: aesedp_setup (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25DEBE3: cbc_start (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E15BB: CCCryptorCreateFromDataWithMode (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E178D: CCCryptorCreateFromData (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E0DFC: CCCryptorCreate (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E1DC6: CCCrypt (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x6E1E8C7: -[NSPersistentUIManager init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x6E1E7B4: __PersistentUIManager_block_invoke_1 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x532841A: _NSFaultInObject (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
    ==15667== by 0x6EED89D: -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x6EED801: -[NSWindow orderWindow:relativeTo:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x6EED0A2: -[NSWindow makeKeyAndOrderFront:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x133EE92: QWidgetPrivate::show_sys() (in /Users/user/QtSDK/Desktop/Qt/4.8.0/gcc/lib/QtGui.framework/Versions/4/QtGui)
    ==15667== by 0x13F9017: QWidgetPrivate::show_helper() (in /Users/birne/QtSDK/Desktop/Qt/4.8.0/gcc/lib/QtGui.framework/Versions/4/QtGui)
    ==15667== by 0x13F934E: QWidget::setVisible(bool) (in /Users/user/QtSDK/Desktop/Qt/4.8.0/gcc/lib/QtGui.framework/Versions/4/QtGui)
    ==15667== by 0x10000724E: QWidget::show() (qwidget.h:494)
    ==15667== by 0x10000943B: MainWindow::showStartupSplash() (mainwindow.cpp:213)
    ==15667== by 0x10000A252: MainWindow::MainWindow(QWidget*) (mainwindow.cpp:52)
    ==15667== by 0x1000070C2: main (main.cpp:8)
    ==15667== Your program just tried to execute an instruction that Valgrind
    ==15667== did not recognise. There are two possible reasons for this.
    ==15667== 1. Your program has a bug and erroneously jumped to a non-code
    ==15667== location. If you are running Memcheck and you just saw a
    ==15667== warning about a bad jump, it’s probably your program’s fault.
    ==15667== 2. The instruction is legitimate but Valgrind doesn’t handle it,
    ==15667== i.e. it’s Valgrind’s fault. If you think this is the case or
    ==15667== you are not sure, please let us know and we’ll try to fix it.
    ==15667== Either way, Valgrind will now raise a SIGILL signal which will
    ==15667== probably kill your program.
    ==15667==
    ==15667== Process terminating with default action of signal 4 (SIGILL)
    ==15667== Illegal opcode at address 0x25E6C0B
    ==15667== at 0x25E6C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E49E0: aesedp_setup (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25DEBE3: cbc_start (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E15BB: CCCryptorCreateFromDataWithMode (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E178D: CCCryptorCreateFromData (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E0DFC: CCCryptorCreate (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x25E1DC6: CCCrypt (in /usr/lib/system/libcommonCrypto.dylib)
    ==15667== by 0x6E1E8C7: -[NSPersistentUIManager init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x6E1E7B4: __PersistentUIManager_block_invoke_1 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x532841A: _NSFaultInObject (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
    ==15667== by 0x6EED89D: -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667== by 0x6EED801: -[NSWindow orderWindow:relativeTo:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
    ==15667==

  6. PhilippeWaroquiers wrote on :

    Note that a 3.7.0 SVN version of Valgrind+gdbserver
    was (manually) tested on Mac.
    The error seen by dc is probably because the
    default gdb in OS X dev tools is too old
    and does not understand the “target remote |”.
    IIRC, the target remote | appeared in gdb 6.5.

    Two solutions:
    * use vgdb –port=xxxx option
    and use in gdb:
    target remote :xxxx
    or
    * compile/install a newer gdb version