lldb fails to examine any variable with the message - Interpreting the expression locally failed: Interpreter couldn't write to memory

Subprojects LLDB
#1

lldb build from trunk running on Ubuntu 12.04 is not able examine any variable.

$cat test1.c
int main(int argc, char argv)
{
    char *crash=0;

    *crash = 0;
    return 0;
}

$gcc -O0 -g3 ./test1.c

$lldb ~/a.out
Current executable set to '/mts/home3/jacobs/a.out' (x86_64).

(lldb) run
Process 16615 launched: '/mts/home3/jacobs/a.out' (x86_64)
Process 16615 stopped
* thread #1: tid = 0x40e7, 0x00000000004004cb a.out`main(argc=1,
argv=0x00007fff336ad2a8) + 23 at test1.c:5, stop reason = invalid
address
    frame #0: 0x00000000004004cb a.out`main(argc=1,
argv=0x00007fff336ad2a8) + 23 at test1.c:5
   2 {
   3 char *crash=0;
   4
-> 5 *crash = 0;
   6 return 0;
   7 }
(lldb) p argc
error: Interpreting the expression locally failed: Interpreter
couldn't write to memory

But before crashing If a breakpoint was setup, lldb stops at the
breakpoint and works fine.

Is it a known issue or should a file a bug report?

Samuel

#2

Hi Dan,

Can you please check this?

Thanks
Samuel

#3

Hi Samuel, thanks for your test case. At first glance, it looks like a new
bug.

My colleague Ashok will confirm this and get back to you ASAP.

Cheers,
Dan

#4

FYI

crash-expr.patch (3.36 KB)

#5

Thanks Ashok and Dan for looking into this.

Please go ahead and file a bug.

#6

http://llvm.org/bugs/show_bug.cgi?id=15784

I am writing frontend using lldb+python and completely blocked on this.
I guess all Linux user/developers would be blocked if they are using trunk.
Somebody please fix this issue.

Thanks
Samuel

#7

Greg, Sean,

Is there a way to rework the lldb interpreter to read variables after a crash? Currently, lldb injects a variable to store the result of expression evaluation. One alternative is to use ptrace to handle a pure read on Linux...

- Ashok

#8

Greg, Sean,

Is there a way to rework the lldb interpreter to read variables after a crash?

Is this a problem because the expression parser can't allocate memory after you have crashed?

LLDB does like to place a copy of the result in the program memory, but it doesn't have to. We could change that.

Currently, lldb injects a variable to store the result of expression evaluation.

Do you mean injects memory into the inferior?

One alternative is to use ptrace to handle a pure read on Linux...

The IR interpreter will not run code for anything that it can handle (like memory and register reads). It might be that we are missing a common IR opcode that linux uses which forced JIT'ed code to run more often?

To verify: is your question regarding that fact that we can't allocate memory when crashed? Can't run code when crashed? What is the real issue?

Greg

#9

Yes please change that. In case of coredumps the program is already
crashed and lldb cant allocate memory from it.

Thanks
Samuel

#10

IIRC, gdb can call functions and allocate memory (which it needs to pass strings to functions among other things) and the like on a crashed program on Linux. Been a while since I looked at how gdb works on Linux, but if gdb can do that, lldb should be able to as well.

Jim

#11

Ø To verify: is your question regarding that fact that we can’t allocate memory when crashed? Can’t run code when crashed? What is the real issue?

The behavior may have changed in the last couple of weeks. With trunk, during PrepareToExecuteJITExpression, EntityVariable::Materialize calls AddressOf on the ValueObject for the variable being examined. This fails, and I’m currently trying to understand the failure by comparing the operation with the same expression evaluation just prior to the crash. Thanks for the helpful perspective on this thread. I’ll try to have a closer look early next week,

  • Ashok