This seems to be intermittent, and after adding additional debugging I cannot currently reproduce it.

I did observe the behaviour w/ DTrace on one occasion, and observed that the DoReadMemory(..., ..., bp_opcode_size) call still returned bp_opcode_size (indicating the bytes were read successfully) even though the underlying ptrace(PT_IO, ...) call returned < 0 with errno = EFAULT. This is not the cause of the problem, but makes the resulting error or log message less clear as to the failure.

I've received a report with additional details on this issue, and it turns out the symbol addresses end up being (incorrectly) modified after stopping:

(lldb) b main
Breakpoint 1: where = a.out`main + 28 at test.c:7, address = 0x000000000040061c
(lldb) process launch
Process 32321 launched: './a.out' (x86_64)
Process 32321 stopped

• thread #​1: tid = 32321, 0x000000000080061c a.outmain + 28 at test.c:7, stop reason = breakpoint 1.1 frame #​0: 0x000000000080061c a.outmain + 28 at test.c:7
  (lldb) breakpoint list
  Current breakpoints:
  1: name = 'main', locations = 1, resolved = 1, hit count = 1
  1.1: where = a.out`main + 28 at test.c:7, address = 0x000000000080061c, resolved, hit count = 1

From a single run of a debugging session:

SectionLoadList::SetSectionLoadAddress (section = 0x807ffbd80 (../tools/lldb/test/python_api/thread/test_step_out_of_malloc_into_function_b_with_dwarf..interp), load_addr = 0x0000000000400200) module = 0x807cdda00

SectionLoadList::SetSectionLoadAddress (section = 0x807ffbd80 (../tools/lldb/test/python_api/thread/test_step_out_of_malloc_into_function_b_with_dwarf..interp), load_addr = 0x0000000000800200) module = 0x807cdda00

The second one comes from DynamicLoaderPOSIXDYLD::LoadAllCurrentModules(). On FreeBSD we see the main module in the link map, with the base address 0x400000. This gets added to the symbol address, so 0x400000 (base addr) + 0x400200 (main) gives 0x800200.

http://llvm-reviews.chandlerc.com/D2319

Workaround committed to the FreeBSD repository, pending the real fix: http://svnweb.freebsd.org/changeset/base/258873

"Proper" fix in review in http://reviews.llvm.org/D2389

It appears this is resolved by:
http://reviews.llvm.org/D8296 (committed)
http://reviews.llvm.org/D10267 (not yet committed)

Following commit of http://reviews.llvm.org/D10267 ( rL239195 ), the problem still exists when debugging an a.out referenced as a relative PATH

lldb ./a.out

or
lldb
(lldb) file ./a.out

Curious enough, I can reproduce this only at the first connection of a given LLDB session, i.e.:

start the server: ./bin/lldb-server g :1234 ./a.out

(lldb) gdb-remote 1234
Process 891 stopped

• thread #​1, name = 'a.out', stop reason = signal SIGSTOP
  frame #​0: 0x000000080020c8b0 ld-elf.so.1
  -> 0x80020c8b0: xorq %rbp, %rbp
  0x80020c8b3: subq $0x18, %rsp
  0x80020c8b7: movq %rdi, %r12
  0x80020c8ba: movq %rsp, %rsi
  (lldb) b main
  Breakpoint 1: where = a.out`main, address = 0x0000000000201910
  (lldb) cont
  Process 891 resuming
  (lldb) warning: failed to set breakpoint site at 0x401620 for breakpoint -2.1: error: 9 sending the breakpoint request
  Process 891 stopped
• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x0000000000401910 a.outmain a.outmain:
  -> 0x401910 <+0>: pushq %rbp
  0x401911 <+1>: movq %rsp, %rbp
  0x401914 <+4>: subq $0x10, %rsp
  0x401918 <+8>: movl $0x0, -0x4(%rbp)
  (lldb) kill
  Process 891 exited with status = 9 (0x00000009)

restart the server but keep client running

(lldb) gdb-remote 1234 [2/1908]
Process 896 stopped

• thread #​1, name = 'a.out', stop reason = signal SIGSTOP
  frame #​0: 0x000000080020c8b0 ld-elf.so.1
  -> 0x80020c8b0: xorq %rbp, %rbp
  0x80020c8b3: subq $0x18, %rsp
  0x80020c8b7: movq %rdi, %r12
  0x80020c8ba: movq %rsp, %rsi
  (lldb) cont
  Process 896 resuming
  Process 896 stopped
• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x0000000000201910 a.outmain a.outmain:
  -> 0x201910 <+0>: pushq %rbp
  0x201911 <+1>: movq %rsp, %rbp
  0x201914 <+4>: subq $0x10, %rsp
  0x201918 <+8>: movl $0x0, -0x4(%rbp)

This seems to be the cause:

lldb DYLDRendezvous::DYLDRendezvous cannot cache exe module path: null executable module pointer

Ok, I think I understand the problem. The executable path is cached in constructor, while DynamicLoaderPOSIXDYLD establishes it later in DidAttach() case. It works for the second connection because LLDB still has the filename from the first connection, i.e. it is wrong still.

Fix for my instance submitted as:
https://reviews.llvm.org/D92264