How to have LLDB print the locations of shared libraries in memory?

Question

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)

Groh

Answer 1

(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.

Abiosis

Thank you, this answers my question. Trying out these commands unfortunately leads to "error: the target has no associated executable images", but I suppose that this is expected when using LLDB on valgrind. – Groh

@DanielTrebbien, I am surprised at this result. I tried this on my machine and it worked fine (though it lists the memory map for valgrind, not the nested guest executable). That is expected. Of course, this comment is now over 2 years old .. – Barboza

Answer 2

It has been a long time since I used valgrind, I totally forgot how debugging worked with it...

To debug a program that is running under valgrind, you have to tell valgrind to open a gdbserver port for the debugger to talk to. Valgrind knows how to undo all it's magic, and pretend that the program it is managing is just an ordinary program...

That's described in Section 3.2 in:

http://valgrind.org/docs/manual/manual-core-adv.html.

LLDB also knows how to talk using the gdb remote protocol, and has a command gdb-remote to connect to the server.

This doesn't work with lldb straight out of the box, it appears there's some issue with the register definitions. It looks like there's some work on valgrind to improve this:

https://bugs.kde.org/show_bug.cgi?id=356174

But anyway, that's how it is supposed to work.

Abiosis