Every time I try to run valgrind on my OS X 10.8 notebook, I get:
bad executable (no stack)
valgrind: ./a.out: cannot execute binary file
What is the problem? How can I fix this? Everything works fine on Linux, so it's not that I'm somehow misusing valgrind. The exact line I'm using is valgrind --tool=memcheck --leak-check=full ./a.out.
I was getting the same error, but I just upgraded valgrind to 3.8.1 (brew upgrade valgrind using HomeBrew for me), and it works, although running Valgrind prints the following warning:
WARNING: Support on MacOS 10.8 is experimental and mostly broken.
WARNING: Expect incorrect results, assertions and crashes.
WARNING: In particular, Memcheck on 32-bit programs will fail to
WARNING: detect any errors associated with heap-allocated data.
I had this problem using valgrind with macports. It turns out I needed to install with
sudo port install valgrind +universal
I was trying to valgrind a 32bit executable and I believe that without +universal, 32bit support was not being compiled in.
Related
I am unable to successfully utilize the pdf-tools package.
Environment:
macOS Monterey 12.0.1
Emacs 27.2
To the best of my understanding, I have followed the installation instructions as outline on https://github.com/politza/pdf-tools:
I've installed and confirmed that the installations of poppler and automake are up-to-date
Though it doesn't seem to be required for the MacOS install, I've installed and confirmed that the installations of gcc and glib are up-to-date.
I've set the PKG_CONFIG_PATH in the init.el file using setenv and confirmed its settings using getenv
(setenv "PKG_CONFIG_PATH" "/usr/local/Cellar/zlib/1.2.8/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/X11/lib/pkgconfig")
When I try to execute pdf-tools-install and select y in response to the question "Need to (re)build the epdfinfo program, do it now?" I get a compilation error which reads:
mode: compilation; default-directory: "~/.emacs.d/elpa/pdf-tools-20211110.513/build/server/"
Comint started at Thu Dec 2 09:17:05
/Users/username/.emacs.d/elpa/pdf-tools-20211110.513/build/server/autobuild -i /Users/username/.emacs.d/elpa/pdf-tools-20211110.513/
Failed to recognize this system, trying to continue.
Configuring and compiling
No such program: autoreconf
Comint exited abnormally with code 1 at Thu Dec 2 09:17:05
I have confirmed that the referenced directory exits and that autoreconf is installed and up-to-date.
For a long while, I had a working pdf-tools setup on my Mac (thank you Andreas Politz and all the other contributors for such a fabulous tool). Suddenly, I don´t really know how or why, it stopped working. I also deleted my homebrew HEAD version of pdf-tools, which made things worse, because I have never again managed to install pdf-tools from Homebrew.
I tried many tweaks, until, finally, I believe the trick that really got things running again was setting the PKG_CONFIG_PATH to everything that mattered inside the init.el file (and downloading XQuartz to get a X11 environment, with the only purpose of having renderproto in the system; it may have been available in an easier way, but it was only like this that I managed to do it).
Here are all the key steps involved in getting pdf-tools back to work in my MacOS Monterey 12.5 running Emacs 28.1 :-)
Download and install XQuartz to get X11 in your Mac (this might be unnecessary, but it helped me).
In case you haven't already, install other dependencies through homebrew:
brew install poppler automake pkg-config
Through M-x list-packages, install pdf-tools.
In your init.el file, set the PKG_CONFIG_PATH using setenv:
(setenv "PKG_CONFIG_PATH" "/usr/local/Cellar/zlib/1.2.12/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/X11/lib/pkgconfig:/usr/local/Cellar/poppler/22.06.0_1/lib/pkgconfig:/opt/x11/share/pkgconfig")
Of course, you will have to use your own version numbers and update them every time you upgrade zlib and poppler. (zlib now ships with mac OS. If like me you're on mac OS 12.6 or later--and most probably even earlier--you can use /usr/local/opt/zlib/lib/pkgconfig:, which won't have to be updated manually).
Personally, I did all this through the use-package configuration macro that helps organize the init.el file:
(use-package pdf-tools
:ensure t
:config
(setenv "PKG_CONFIG_PATH" "/usr/local/Cellar/zlib/1.2.12/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/X11/lib/pkgconfig:/usr/local/Cellar/poppler/22.06.0_1/lib/pkgconfig:/opt/x11/share/pkgconfig")
(pdf-tools-install)
(custom-set-variables
'(pdf-tools-handle-upgrades t)))
Close Emacs and and re open it in the Terminal and, type y when prompted to "(re)build the epdfinfo program". (For some reason, rebuilding the epdfinfo program seems to work better in the Terminal than in the GUI version of Emacs).
That's all it should take to get pdf-tools to work. It did for me, anyway.
try installing the package 'autoconf' the same way you installed 'automake'.
I following this guide:
valgrind installation guide
After I have downloading the package, and I have run the sh script, but when I launch the make install command, it couldn't create the folder because it don't have the permission (even though I have used the sudo command).
Furthermore I tried with brew but I have this error:
valgrind: This formula either does not compile or function as expected on macOS
versions newer than El Capitan due to an upstream incompatibility.
Error: An unsatisfied requirement failed this build.
You can download Valgrind's latest version from their website. Then, you can just ./autogen.sh to install Valgrind. I personally did not encounter anything needed to make.
However, the sad news is, even the most recent version of Valgrind is not very usable on Mac OS Sierra. The reason is that Apple has not released the part of the source code that makes Valgrind crash, without which, the Valgrind maintainers can hardly do anything. You can read more about the discussion around the issue here .
Because Mac OS kernel is under Apple Public Source License, it has to be open-sourced someday. Thus, a Sierra-complitable version of Valgrind is only a matter of time.
Currently, I use Valgrind under Linux. This is all I can suggest now.
Latest Valgrind (git version 3.13.0) now works on MacOS Sierra but needs Xcode command line tools installed (installs needed headers).
Run this before building Valgrind:
xcode-select --install
Thanks goes to this post.
If you get an error similar to
valgrind: This formula either does not compile or function as expected
on macOS versions newer than Sierra due to an upstream
incompatibility.
you can try the workaround brew install --HEAD valgrind I found this information here https://www.gungorbudak.com/blog/2018/04/28/how-to-install-valgrind-on-macos-high-sierra/
If you happen to be on Sierra still, this works (but not on High Sierra), just do
$ brew install valgrind
valgrind: This formula either does not compile or function as expected on macOS
versions newer than Sierra due to an upstream incompatibility.
Error: An unsatisfied requirement failed this build.
Update: seems it works on "High Sierra" OOTB now too, it now says:
...versions newer than High Sierra due to an upstream incompatibility...
The easy alternative to valgrind on mac is called 'leaks'. It is a command-line tool, so if you don't already have xcode command-line tools installed, do so with
'xcode-select --install'.
Then, to test for leaks, just compile your prog then run
'leaks -atExit -- ./your_prog'
I'm relatively new to mac and now trying to setup a dev. environment for Cordova based iOS app. I'm using Yosemite 10.10.3
I've installed xcode 6.3.1 and the commandlinetools for 6.3.1, under /Applications/Xcode.app/Contents/Developer/ I can see usr/bin and usr/lib, also xcode-select -p is pointing to this path, so I think the command line tool is fine.
However, when I run xcodebuild I got command not found. I've manually added the path above into the PATH environment variable to make xcodebuild visible, but not sure why this is needed, I thought the installation should have taken care of this.
Then when xcrun was executed in certain script ( npm install -g ios-deploy ), I got the following error:
dyld: Library not loaded: #rpath/libxcrun.dylib referenced from /usr/bin/xcrun, reason: image not found.
I see xcrun is available in /usr/bin as well as in the usr/bin under command line tool installation path. But the libxcrun.dylib is only available in the installation path.
I manually copied this dynamic library to /usr/lib and xcrun worked.
Though it seemed working but I got suspicious, such manual actions shouldn't be the normal post-installation procedure, should they?
Is there something I forgot to do after the command line installation? What if there's more such little files I need to copy/move around? Can I simply specify the installation path somewhere?
BTW, I added the install path/usr/lib into PATH, but didn't work with xcrun, had to copy the .dylib.
There's other mac which the Xcode and CLT were upgraded from previous version, and there no such issue.
Well, after some try-out I've got ios-deploy installed by npm. I'm not sure if what I did is preferred resolution, to me it's more like a workaround.
First of all, as far as I see, if it was upgraded from previous version of CLT or Xcode, such issue doesn't exist, though all the executable behaviour are the same.
e.g. /usr/bin/xcrun will be used, and /usr/lib doesn't have libxcrun.dylib, while #executable_path=../lib, meaning xcrun is looking for library in the ../lib location.
Normally the library not loaded error is expected, but somehow with the upgraded case some hidden setting told xcrun to search for library in the correct path.
I've tried DYLD_LIBRARY_PATH, worked with gcc and xcrun but didn't work with npm install. I can only fix the error by copying the lib file to /usr/lib at the moment.
Well, I'm still getting "cannot infer developer directory from our own path (/usr/bin/xcrun)" warning, even though I've set DEVELOPER_DIR to the correct one, and xcode-select -p shows the same.
But this warning seems not doing harm to npm install -g ios-deploy ...... therefore I can live with it for now.
So the mystery persisted. I still don't know why /usr/bin/xcrun has to be used instead of CLT/usr/bin/xcrun, I still don't know how in the upgraded case /usr/bin/xcrun managed to locate the correct lib file and didn't throw any warning. What's the difference between the new installation and upgrade?
This answer is just providing a workaround to continue without recreating everything on the machine.
Additional information:
As shown in comments, afterwards I found ios-sim is not working, always crash with exception, thus I had to reinstall OS and started over. The issue disappeared. Now the only difference I can remember, is I installed mac ports in between of OS and xcode during last time.
My recommendation would be, install Xcode right after the OS to avoid unexpected system changes.
I have a project that for the time being has to be compiled in 32 bit mode. I'm on Ubuntu 11.04 -64 bit and it works fine with the -m32 switch.
Now I wanted to debug with the -fmudflap option, but I get a series of undefined functions (__real_malloc, __real_calloc, __real_free, etc.).
I tested with a trivial hello world program and it works fine in a 64bit compile, but not in 32bit mode.
Is there a different library to link besides -lmudflap ?
It sounds like you need to install the 32-bit version of mudflap.
I installed valgrind on Snow Leopard using the patch at https://bugs.kde.org/show_bug.cgi?id=205241 . However, when I run it with a binary I compiled from C++ code, I'm told that valgrind "cannot execute binary file". What g++ flags should I set to make my program work with valgrind?
Be sure to use the -m32 option to generate a 32-bit executable. The compiler default is 64-bit (assuming you have a 64-bit machine), but valgrind does not yet officially support 64-bit executables on Mac OS X. The file command on your executable should report "Mach-O executable i386".