This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] avoid the crash of gdb+pretty printer on initialized local variables


Hi, gdb developers.

When debugger with python pretty printer, I sometimes get the gdb crash
when I try to show the value of uninitialized local variables. As you
know, an uninitialized local variable can contain some random value, so
the pretty printer try to interpret those values, and can cause the gdb
to an long loop or crash.

The patch is just a work-around/hack to handle this problem.
I just first check if the symbol is a local variable, and then check the
current line SAL is smaller than the variable's declaration line. If
true, which means this local variable is OK to show, if not, than I just
skip it.

The first patch try to deal with the "info locals" problem, the local
variable defined later than the current line will be skipped.
The second patch try to skip/filter the same local variables.

For example:

void fun()
{
    wxString *psty = (wxString*) NULL;
    wxString wxStr(L"wxString");
    wxStr += L" Value";
    std::string stdStr("std::string");
    stdStr.append(" value");
    std::map<int, std::string> m;
    m[0] = "000";
    m[1] = "111";     //break point here, we stop here

   

    wxString& wxStrRef = wxStr;
    wxStrRef += L" Ref";
    std::string& stdStrRef = stdStr;
    stdStrRef += " Ref";

    std::list<std::string> l = {"a", "b", "c"};
    std::vector<std::string> v = {"a", "b", "c"};
    std::queue<std::string> q;
    q.push("a");
    q.push("b");

    std::stack<std::string> s;
    s.push("a");
    s.push("b");
}

Now, you have stopped on the breakpoint. the local variable "l,v,q" is
after the breakpoint line.
If you try to run "print v", or "info locals", then gdb will crash (I'm
using gdb cvs build under WindowsXP, mingw, python 2.7)

I believe that this patch will not be applied, because it is just a
hack, right?
I just also CC to mingw maillist hope they have some interests.

Basically, gdb should alive with out any crash in any condition, but
sometimes, I think a workaround is also necessary. I have see that in
QTcreator, when they want to show the contents of a stl container, it do
many sanity check. like:

The length of the std::vector should be positive, and it's size should
be limited.
Also many other sanity checks

asmwarrior
ollydbg from codeblocks forum


 gdb/stack.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/gdb/stack.c b/gdb/stack.c
index c51832e..317570d 100644
--- a/gdb/stack.c
+++ b/gdb/stack.c
@@ -1825,6 +1825,10 @@ iterate_over_block_locals (struct block *b,
 {
   struct dict_iterator iter;
   struct symbol *sym;
+  struct frame_info *frame;
+  struct symtab_and_line sal;
+  frame = get_selected_frame (NULL) ;
+  find_frame_sal (frame, &sal);
 
   ALL_BLOCK_SYMBOLS (b, iter, sym)
     {
@@ -1836,6 +1840,8 @@ iterate_over_block_locals (struct block *b,
 	case LOC_COMPUTED:
 	  if (SYMBOL_IS_ARGUMENT (sym))
 	    break;
+	  if(sym->line>= sal.line)
+            break;
 	  (*cb) (SYMBOL_PRINT_NAME (sym), sym, cb_data);
 	  break;
 


 gdb/symtab.c |   29 +++++++++++++++++++++++++++--
 1 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/gdb/symtab.c b/gdb/symtab.c
index 65e4248..2047351 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -1730,6 +1730,8 @@ lookup_block_symbol (const struct block *block, const char *name,
 {
   struct dict_iterator iter;
   struct symbol *sym;
+  struct frame_info *frame;
+  struct symtab_and_line sal;
 
   if (!BLOCK_FUNCTION (block))
     {
@@ -1739,7 +1741,20 @@ lookup_block_symbol (const struct block *block, const char *name,
 	{
 	  if (symbol_matches_domain (SYMBOL_LANGUAGE (sym),
 				     SYMBOL_DOMAIN (sym), domain))
-	    return sym;
+	    {
+	       if(SYMBOL_CLASS (sym)==LOC_LOCAL
+	          ||SYMBOL_CLASS (sym)==LOC_REGISTER
+		  ||SYMBOL_CLASS (sym)==LOC_COMPUTED)	  
+	       {
+		   frame = get_selected_frame (NULL) ;
+		   find_frame_sal (frame, &sal);
+		   if( block == get_frame_block (frame, 0) 
+		      && sym->line >= sal.line)
+			return NULL;
+	       }
+	       return sym;
+	    }
+	    
 	}
       return NULL;
     }
@@ -1763,7 +1778,17 @@ lookup_block_symbol (const struct block *block, const char *name,
 	      sym_found = sym;
 	      if (!SYMBOL_IS_ARGUMENT (sym))
 		{
-		  break;
+		   if(SYMBOL_CLASS (sym)==LOC_LOCAL
+	              ||SYMBOL_CLASS (sym)==LOC_REGISTER
+		      ||SYMBOL_CLASS (sym)==LOC_COMPUTED)
+	           {
+			  frame = get_selected_frame (NULL) ;
+			  find_frame_sal (frame, &sal);
+			  if(block == get_frame_block (frame, 0) 
+			  && sym->line >= sal.line)
+			       sym_found = NULL;
+	           }
+		   break;
 		}
 	    }
 	}



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]