Sometime in the last month lldb on FreeBSD reports this error, although the breakpoint actually does get set. Using the dictionary.c example / tutorial code, feynman% bin/lldb /tank/emaste/src/snippets/dictionary Current executable set to '/tank/emaste/src/snippets/dictionary' (x86_64). (lldb) b find_word warning: failed to set breakpoint site at 0x400e60 for breakpoint 2.1: failed to verify the breakpoint trap in memory. (lldb) run romeo-and-juliet.txt Process 75214 launched: '/tank/emaste/src/snippets/dictionary' (x86_64) Dictionary loaded. Enter search word: Romeo Process 75214 stopped * thread #1: tid = 102845, 0x0000000000400e60 dictionary`find_word(dictionary=0x0000000800c4b040, word=0x00007fffffffd0a0) + 16 at dictionary.c:126, stop reason = breakpoint 2.1
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.out`main + 28 at test.c:7, stop reason = breakpoint 1.1 frame #0: 0x000000000080061c a.out`main + 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.out`main a.out`main: -> 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.out`main a.out`main: -> 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