I am trying to gather as much information as I can about an apparent infinite loop issue seen when using Valgrind 3.11.0 on Mac OS 10.11.1 'El Capitan'.
When I run valgrind
on my program in LLDB or attach to valgrind
running my program and then stop the process, I get a backtrace like the following:
* thread #1: tid = 0x24ab4, 0x000000010805920b, stop reason = signal SIGSTOP * frame #0: 0x000000010805920b frame #1: 0x0000000108040dda frame #2: 0x00000001080b6790 frame #3: 0x00000001080b2fd3 frame #4: 0x00000001080b7c25 frame #5: 0x00000001080b6113 frame #6: 0x00000001080b3cd0 frame #7: 0x00000001080c54d9
How do I tell which object(s) these frames correspond to?
I tried vmmap
on the process, but it's not showing any information. In particular, the "Non-writable regions for process" section which would normally show the address ranges where the dylibs were mapped into the process' memory is blank:
$ vmmap -v 21729 Process: memcheck-amd64-darwin [21729] Path: /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/memcheck-amd64-darwin Load Address: 0x100000000 Identifier: memcheck-amd64-darwin Version: ??? Code Type: X86-64 Parent Process: bash [11895] Date/Time: 2015-11-30 11:52:16.392 -0500 Launch Time: 2015-11-30 11:51:53.557 -0500 OS Version: Mac OS X 10.11.1 (15B42) Report Version: 7 Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/vmmap Analysis Tool Version: Xcode 7.1.1 (7B1005) ---- Virtual Memory Map of process 21729 (memcheck-amd64-darwin) Output report format: 2.4 -- 64-bit process VM page size: 4096 bytes ==== Non-writable regions for process 21729 REGION TYPE START - END [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE REGION DETAIL ==== Writable regions for process 21729 REGION TYPE START - END [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE REGION DETAIL ==== Legend SM=sharing mode: COW=copy_on_write PRV=private NUL=empty ALI=aliased SHM=shared ZER=zero_filled S/A=shared_alias PURGE=purgeable mode: V=volatile N=nonvolatile E=empty otherwise is unpurgeable ==== Summary for process 21729 (null)
(lldb) image lookup -va <ADDRESS>
will show a bunch of information about a given address, and:
(lldb) image list
will list all the libraries, and
(lldb) image dump sections
will dump detailed information about the section locations of all the loaded libraries.
However, if lldb had been able to figure out what library was mapped at a given address in the frame printing, it would have shown that (unless you've altered the frame-format setting.) So these commands may not show you much more either.
Note, valgrind does weird things to the execution of your program in order to work its magic, and I wouldn't be at all surprised if external tools like lldb & vmmap aren't able to see the underlying truth.
Since you have a recent OS & tools, you might try llvm's ASAN instead of valgrind, and see if it catches your issue. ASAN requires a rebuild, but because it does its tricks statically the runtime looks normal to other tools.