[lldb-dev] Bug? in evaluation

[jingham at apple.com]

That is not the intention of the design, and also not what I see:

(lldb) source list -f foo.c -l 1
   1   	#include <stdio.h>
   2   	
   3   	int
   4   	foo (int input)
   5   	{
   6   	  int local_var = input * 5;
   7   	  printf ("Local var: %d.\n", local_var);
   8   	  return local_var;
   9   	}
   10  	
   11  	int
(lldb) 
   12  	main (int argc, char **argv)
   13  	{
   14  	  int local_var = argc;
   15  	  printf ("Foo returns: %d.\n", foo (local_var));
   16  	  return 1;
   17  	}
(lldb) b s -p "return local_var"
Breakpoint 1: where = foo`foo + 41 at foo.c:8, address = 0x0000000100000ef9
(lldb) run
Process 98518 launched: '/private/tmp/foo' (x86_64)
Local var: 5.
Process 98518 stopped
* thread #1: tid = 0x3663ec, function: foo , stop reason = breakpoint 1.1
    frame #0: 0x0000000100000ef9 foo`foo at foo.c:8
   5   	{
   6   	  int local_var = input * 5;
   7   	  printf ("Local var: %d.\n", local_var);
-> 8   	  return local_var;
   9   	}
   10  	
   11  	int

So I am in foo, there is a "local_var" in frame 0, where its value is 5, and in frame 1 where its value is 1.  So I do:

(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> frame_0 = lldb.thread.GetFrameAtIndex(0)
>>> print frame_0.EvaluateExpression("local_var")
(int) $0 = 5
>>> frame_1 = lldb.thread.GetFrameAtIndex(1)
>>> print frame_1.EvaluateExpression("local_var")
(int) $1 = 1
>>> quit()

SBFrame::EvaluateExpression, at least in this example, works on the SBFrame that you call it on.

Note, here I am using lldb.thread, which is INDEED the command interpreter's currently selected thread.  I just did that to shorten the example.  If you wanted to get the process/thread/frame independent of entities selected in the Command Interpreter, then you should use the accessors on SBDebugger, SBTarget, SBProcess and SBThread.  The Python docs explicitly state that you should NOT use lldb.process/lldb.thread or lldb.frame anywhere but in the interactive script interpreter.  They aren't even guaranteed to be set in other contexts.

Anyway, if you have some example (not using lldb.process/lldb.thread/lldb.frame) where the EvaluateExpression on a SBFrame object is evaluating the expression is the context of some other frame, please file a bug and we will take a look.

Jim


On Jun 10, 2013, at 1:46 PM, Andrey Zaytsev <andrey.zaytsev at jetbrains.com> wrote:

> Hello everyone.
> 
> I just realised thing which leads to crash of debuggee in some cases. We had a bug in our tracker: http://youtrack.jetbrains.com/issue/OC-7389
> 
> We have some system of value renderers. Each renderer(e.g for NSCollections) evaluates some stuff to get info about collection elements. So does a number of Summary and Synthetic Providers too.
>  
> In SB-API it is implemented with EvaluateExpression function. One of the ways we can evaluate expression is to call lldb::SBFrame::EvaluateExpression() member function. Actually it performs execution on selected thread/frame. But not on the frame we call EvaluateExpression function on. It's very not obvious and in my opinion buggy. Usage of API in this way leads to crashes of debuggee process like in the ticket above. So crashes not only attempt to evaluate expression but attempt to get local variables with dynamic types if it executes target as well.
> 
> So workaround for us was to select specified thread/frame before doing evaluation. So does interpreter's expr command.
> 
> 
> -- 
> Andrey Zaytsev
> Software Developer
> JetBrains, Inc
> http://www.jetbrains.com/
> "Develop with pleasure!"
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev