On Apr 25, 2013, at 1:47 PM, "Thirumurthi, Ashok" <[email protected]> wrote:
> 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 > > - Ashok > > -----Original Message----- > From: Samuel Jacob [mailto:[email protected]] > Sent: Wednesday, April 24, 2013 2:51 PM > To: Thirumurthi, Ashok > Cc: [email protected] > Subject: Re: [lldb-dev] lldb fails to examine any variable with the message - > Interpreting the expression locally failed: Interpreter couldn't write to > memory > > 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 > > On Thu, Apr 18, 2013 at 10:24 AM, Thirumurthi, Ashok > <[email protected]> wrote: >> FYI >> >> -----Original Message----- >> From: Thirumurthi, Ashok >> Sent: Thursday, April 18, 2013 11:37 AM >> To: 'Samuel Jacob' >> Subject: RE: [lldb-dev] lldb fails to examine any variable with the >> message - Interpreting the expression locally failed: Interpreter >> couldn't write to memory >> >> Hi Samuel, >> >> Thanks for the test case. I can reproduce this using trunk with >> lldb/tests/functionalities/inferior-crashing, and confirmed that there is no >> existing bug report. For instance, the issue is distinct from >> http://llvm.org/bugs/show_bug.cgi?id=15671. >> >> After the crash, the back-trace is correct, and "register read -a" dumps the >> register set. The expression parser should generate IR that the LLDB >> interpreter can use to read from the address of argc in the inferior. So, >> there is no design requirement to inject code into the inferior to evaluate >> the expression. I suspect that the write is related to a temporary that is >> used to store the result of the read, but it may be possible to rework the >> expression interpreter to eliminate the write. >> >> The attached patch modifies the existing test case to reproduce the issue >> that you've raised (and also checks the register read). If you don't mind, >> I'll log a bugzilla for this in order to cross-reference it with the failing >> test. I've marked the test as xfail on Darwin as well. I'll let folks >> chime in if it's an xpass... >> >> FYI, when run under our test harness, this test fails with 'use of >> undeclared identifier 'argc''. I can reproduce this second issue from >> the command line by issuing 'expr argc' twice, at which point the >> process is no longer in a limbo state. Thanks again, >> >> - Ashok >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Samuel Jacob >> Sent: Wednesday, April 17, 2013 11:53 PM >> To: lldb-dev; Malea, Daniel >> Subject: Re: [lldb-dev] lldb fails to examine any variable with the >> message - Interpreting the expression locally failed: Interpreter >> couldn't write to memory >> >> Hi Dan, >> >> Can you please check this? >> >> Thanks >> Samuel >> >> On Wed, Apr 17, 2013 at 4:21 PM, Samuel Jacob <[email protected]> wrote: >>> 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 >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
