On Mar 30, 2012, at 7:33 AM, Filipe Cabecinhas wrote:
> Hi all,
>
> I'm having a heisenbug in a program that uses lldb. I've implemented a simple
> repl (much like Driver.cpp). My problem is that sometimes the stack traces
> are very weird and don't agree with 'register read rip'.
>
> Example:
> (lldb) bt
> * thread #1: tid = 0x2503, 0x00007fff6dd1226a
> dyld`_ZL18gdb_image_notifier15dyld_image_modejPK15dyld_image_info + 1, stop
> reason = breakpoint 1.1
> frame #0: 0x00007fff6dd1226a
> dyld`_ZL18gdb_image_notifier15dyld_image_modejPK15dyld_image_info + 1
> frame #1: 0x00007fff8ddf8570 libsystem_notify.dylib
> (lldb) register read rip
> rip = 0x000000010e107824 tests`main + 36 at tests.c:15
>
>
>
> Frame #0 says the rip should be near 0x00007fff6dd1226a, but register read
> rip yields 0x000000010e107824.
>
> Disassembling the address from frame #0, I have:
> (lldb) disassemble -C 20 -s 0x00007fff6dd1226a
> dyld`_ZL18gdb_image_notifier15dyld_image_modejPK15dyld_image_info + 1:
> 0x7fff6dd1226a: movq %rsp, %rbp
> 0x7fff6dd1226d: popq %rbp
> 0x7fff6dd1226e: ret
> dyld`setAlImageInfosHalt(char const*, unsigned long):
> 0x7fff6dd1226f: pushq %rbp
> 0x7fff6dd12270: movq %rsp, %rbp
> 0x7fff6dd12273: movq %rdi, 178894(%rip) ; dyld_all_image_infos + 56,
> dyld_all_image_infos + 56
> 0x7fff6dd1227a: movq %rsi, 178895(%rip) ; dyld_all_image_infos + 64,
> dyld_all_image_infos + 64
> 0x7fff6dd12281: popq %rbp
> 0x7fff6dd12282: ret
> dyld`removeImageFromAllImages(mach_header const*):
> 0x7fff6dd12283: pushq %rbp
> 0x7fff6dd12284: movq %rsp, %rbp
> 0x7fff6dd12287: pushq %rbx
>
>
>
> But if I step over one instruction:
> (lldb) register read rip
> rip = 0x000000010e107824 tests`main + 36 at tests.c:15
> (lldb) si
> Process 30849 stopped
> * thread #1: tid = 0x2503, 0x000000010e108540 tests`atoi at atoi.c:9, stop
> reason = instruction step into
> frame #0: 0x000000010e108540 tests`atoi at atoi.c:9
>
>
>
> It manages to catch up with the real address and function, stepping into a
> call to the (home-made) atoi function.
>
> Is this a known bug? I can't reproduce it yet (it just happens, sometimes).
> If I manage to find out why this is happening, I'll ping back the list.
>
> Just to make sure there are no mistakes: I have not seen this problem in
> Driver.cpp. Only in my program (that mimics most of Driver.cpp's structure
> and calls).
>
> Any ideas?
If I can see your code, I might be able to explain why this is happening. This
shouldn't be able to happen, but we have seen some odd behaviour when trying to
add python breakpoint scripts, which might be similar to what you are running
into. For example if you do:
(lldb) breakpoint set --name printf
(lldb) breakpoint command add -s python
>>> print frame
>>> thread = frame.GetThread()
>>> frame.GetThread().StepOver()
>>> new_frame = thread.GetFrameAtIndex(0)
>>> print new_frame
>>> DONE
As a reminder, the function prototype for a python breakpoint command callback
function is "def bp_hit_callback (frame, bp_loc)" so the commands above are run
as:
def bp_hit_callback (frame, bp_loc):
print frame
thread = frame.GetThread()
frame.GetThread().StepOver()
new_frame = thread.GetFrameAtIndex(0)
print new_frame
In this case we are seeing that the new_frame is often the same as the old
frame.
Greg Clayton
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
