Debuging C on Mac OS Sierra - c

I currently have Mac Sierra 10.12.3 and I had the surprise that Valgrind is not compatible despite their latest version.
valgrind: mmap-FIXED(0x0, 253952) failed in UME (load_segment1) with error 12 (Cannot allocate memory).
I wanted to know if there was a solution to solve this problem or another debugger (gdb does not work either).
I prefer not to use XCode because I like to program with a terminal.
Thank you

Use LLDB as described in this article http://www.developerfiles.com/debugging-c-with-clang-compiler-and-lldb/

Related

MacOS Valgrind alternative?

I'm running MacOS Big Sur and trying to install valgrind for an assignment.
brew install valgrind doesn't currently work and installing from the tar.bz2 distribution doesn't either.
Running ./configure (according to the readme instructions) returns this at the end:
checking for a supported OS... ok (darwin20.1.0)
checking for the kernel version... unsupported (20.1.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and 17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)
Judging from that, looks like valgrind hasn't worked for the last couple of MacOS releases.
Is there an alternative for current MacOS releases or is this a good time for me to make a partition on my hard drive for Linux? Or am I missing something with installation?
As mentioned in the comments, Louis Brunner's github repo is your best bet at the moment. This should give you at least a minimally functional build.
Other than the usual version number changes, one of the big, breaking, changes in Big Sur is the fact that the system libraries are cached (and hidden) by dyld. So right now Valgrind is not able to read libsystem_malloc.dylib in order to determine the address of functions like malloc so that they can be redirected.
If anyone wants to take a stab at it, then my guess is that you will need to follow these instructions, and change initimg-darwin.c so that dyld_cache_value is "avoid".
For anyone else looking for an answer, you could use valgrind-macos, a fork of Valgrind on macOS, as recommended by PhillipMills. XCode also provides tools for leak checking.
However, if you don’t use XCode and don’t like the first option, you could try Address/Leak Sanitizer. The difference is that you’ll have to compile and link with one of the sanitizers, but that only requires an extra flag, i.e., -fsanitize=address. Note that Apple Clang doesn’t support leak checking, so you’ll have to grab llvm off Brew. Also, you need to prepend ASAN_OPTIONS=detect_leaks=1 before your executable.

valgrind: mmap(0x600000, 8192) failed in UME with error 12 (Cannot allocate memory)

I was following this exercise. This page has instructions to install Valgrind 3.6.1 but this version of Valgrind is not supported by my current Linux kernel version. So, I installed Valgrind 3.11.0 and followed the instructions there after and on running this command:
$ valgrind ./ex4
got this error:
valgrind: mmap(0x600000, 8192) failed in UME with error 12 (Cannot allocate memory).
How to do I fix it?
I'm using Ubuntu 14.04 LTS with kernel version 4.4.0
The error which you have encountered is actually a kernel bug, which was fixed in the subsequent versions. More details here:
https://bugzilla.redhat.com/show_bug.cgi?id=1301093
To overcome the error, I would suggest you to update the kernel.
Note: I am myself using running Ubuntu 14.04 on kernel version 3.16.0-67 and it runs without any hassles.
Edit: As pointed out by the OP in comments, the bug has been fixed in kernel version 4.5.2.

Unable to run c/c++ code on OS X 10.9

For some time now I have been unable to run c or c++ code on my Mac running OS X 10.9. See my earlier post for details on what I tried to do about this originally some time ago:
In Xcode running such code gives me the error: "clang: error: linker command failed with exit code 1 (use -v to see invocation)", which leads me to believe that it is some problem with clang symlinking to gcc, but I am not sure. I have already tried reinstalling OS X to no avail. Is there a way that I could reset everything related to running c/c++ code short of doing a clean install of OS X and manually restoring my files and apps? This has become very frustrating and it seems that there are no answers! Thanks.

Weird segmentation fault in python3 after updated to MAC OS X Mavericks

I've updated my system to OS X Mavericks, just now when I tried to use hashlib module a strange Segmentation fault Raised. I've tried to rebuild the python3.3.2 and reinstall it again but it didn't help. So how could I fix this annoying problem? The out put looks like below:
ZZ:Python-3.3.2 zhangzhao$ python3
Python 3.3.2 (default, Oct 28 2013, 16:27:26)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> a = hashlib.md5()
Segmentation fault: 11
There are known problems with Python 3.3.2 and Mavericks. Please try Python 3.3.3rc1 as this may fix thes problem:
This release fully supports OS X 10.9 Mavericks. In particular, this
release fixes an issue that could cause previous versions of Python to
crash when typing in interactive mode on OS X 10.9
I had the same problem & found the answer here: python3 segmentation fault on osx mavericks
------>
This problem exists because of this bug: http://bugs.python.org/issue18458.
Basically, Python has code in Modules/readline.c that contains a workaround for a bug in libedit, however the bug in libedit was fixed and Mavericks comes with the new version of libedit and the workaround now causes ython to segfault. The quick and dirty fix is to disable deadline processing by running the following command (from the bug document):
curl -O http://bugs.python.org/file32324/patch_readline_issue_18458.sh
openssl sha1 patch_readline_issue_18458.sh
# the digest should be 7cb0ff57820a027dd4ca242eb2418930f8f46b4c
sudo sh ./patch_readline_issue_18458.sh
<------------
This same problem happens with both Python2.7.5 and python3.3.2 for OSX Mavericks 10.9. It was driving me nuts. I couldn't even assign and then invoke a simple variable without crashing the interpreter.
>>> a = 7
>>> a
Segmentation fault: 11
It is bug discussed at issue18458
The patched versions for OSX Mavericks can be found below for Python 2 and 3 respectively.
http://www.python.org/download/releases/2.7.6/
http://www.python.org/download/releases/3.3.3/

Running a program compiled from clang+llvm on another machine

I am compiling a program through clang+llvm (version 3.1) and trying to run it on a computer which also has the same clang+llvm version. I'm compiling on Ubuntu 10, but the other computer where I'm trying to run has CentOS 5. There (in CentOS), I also encounter problems compiling through LLVM (a compiler pass is implemented in LLVM). That is why I thought about compiling on Ubuntu, take the exe from there and just run it on the CentOS machine.
However, when I try to do that, I get the following error.
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./main)
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./main)
How can I solve this. Please note that I do not have root accesses on that machine.
One solution would be to copy the library from your working Ubuntu machine to your CentOS machine. Put in your Home/Workdir/whereever(TM) and set your LD_PRELOAD variable to that library. But that can be quite tedious as it is possible that this is not the only library that is missing (and maybe libraries depend on other libraries, that you also need...).
This also only works, if both machines have the same architecture (e.g. it wont work if your ubuntu machine is 32 bit and your CentOS 64).
Centos 5 uses an older version of libstdc++ than Ubuntu 11.04 or 11.10, so can't use binaries from there.
Either compile on Centos 5, or find a older compile environment that does work. If you were using gcc, you could also investigate the LSB compiler environment.
Cross compilation is always a difficult issue. In your case you have different c++ library versions on the two machines. In case you do not need to do this often, I suggest you try and solve your compilation issue on CentOS. It's probably the easier way round.

Resources