Bug 11407

-var-update has the same issue.

This issue is really annoying (please read "pretty printers rule, just this 
small bug creates a problem redering them kind ob useless").

The typical C++ developer (including me) declares a variable when it is 
needed, not at the top of the function or method. So, with my Eclipse CDT 
patched to enable the pretty printers for the MI variable objects, and having 
code that often has local variables of types being associated with pretty 
printers, the variables view often remains empty until the end of the method.

I have the impression that fixing this issue isn't possibly too complicated. 
Would it be possible to provide such a patch? This would help to continue with 
the work on Eclipse, and I could use the result for myself or anybody else who 
can use a patched gdb, at least.

For Eclipse CDT, I tend to rate this bug as a blocking issue to really commit 
the support for the pretty printers (besides the value that is provided by -
data-evaulate-expression), as there is no offical gdb version that would have 
fixed that bug, and without the fix, the IDE is not behaving usefully.

This is to say, has this bug really "normal" severity?

(In reply to comment #2)
I even tried to fix all my pretty printers to catch Exception, but it doesn't 
help, because the exception is not thrown in the pretty printer code, but when 
gdb uses the values that are returned by my iterator.

Or is there any other workaround I could try in my pretty printers?

(In reply to comment #3)
> Or is there any other workaround I could try in my pretty printers?
You can omit the value, then you get all local variables again.

Does setting

help maintenance set python print-stack off 

help in this circumstance?

(In reply to comment #5)
> Does setting
> help maintenance set python print-stack off 
> help in this circumstance?
No. Here is what I get:

688,131 37-interpreter-exec console "maintenance set python print-stack off"
688,133 37^done
688,134 (gdb) 
689,771 38-exec-next --thread 1 1
689,773 38^running
689,776 *running,thread-id="all"
689,776 (gdb) 
689,779 *stopped,reason="end-stepping-range",frame=
{addr="0x0000000000400fce",func="main",args=[],fi\
le="../src/sneha.cpp",fullname="/home/jelmenth/Projects/ws-dsf-
test/sneha/src/sneha.cpp",line="60"},\
thread-id="1",stopped-threads="all",core="1"
689,779 (gdb) 
689,821 39-stack-list-locals --thread 1 --frame 0 1
689,824 39^error,msg="Cannot access memory at address 0x64697469617700"
689,826 (gdb) 
689,828 40-stack-info-depth --thread 1 5
689,829 40^done,depth="1"
689,830 (gdb) 

Created attachment 4692 [details]
Mi errors output

I attached the output with the stack listing turned off? In this view you only
see the locals output?

(In reply to comment #7)
> Created an attachment (id=4692)
> Mi errors output
> I attached the output with the stack listing turned off? In this view you 
only
> see the locals output? 
I your transaction an error happens, but -stack-list-locals nevertheless 
returns the locals, and I wouldn't have a real problem in my debugging session.

I my case, -stack-list-locals does not return the locals at a all. Comparing 
your output and my output, the difference is the source of error. In your case 
an exception is thrown in the to_string method of the pretty printer. This 
seems to be handled properly. In my case the pretty printer methods don't 
throw. The error occurs later when gdb accesses one of the elements returned 
as children by the pretty printer.

I'm trying to create a case (via gdb -i=mi2) where I can replicate the crash
when printing the child of value.  print_string_repr (for to_string), and
print_children (for children) do call gdbpy_print_stack which in turn calls
PyErr_Print (). This prints the error and clears the exception. However if in
GDB an python exception is not caught (or cleared as above) it will be converted
to an internal GDB error() call which will terminate the current action GDB was
working on.  There is one case in print_children where gdbpy_print_stack is not
called in a possible error condition (a child that is a string, but not a lazy
string). But trying to produce a testcase is turning out to be a painful
process. Do you have one handy that you could extract from your scenario?

Created attachment 4693 [details]
my example

Set the breakpoint to the top of main. When halted on the breakpoint, I hit
normally hit the problem. Of course it depends on how unfortunate your
uninitialized data currently looks, but I ran into the problem everytime.

I use RedHad EL 5.3, gcc version 4.1.2 20080704 (Red Hat 4.1.2-44), a gdb 7.1
compiled from source, and the pretty printers from the latest STL applied to my
STL

Thanks for the testcase! I've isolated the bug:

380	  for (i = 0; i < options->print_max; ++i)
(top-gdb) 
382	      PyObject *py_v, *item = PyIter_Next (iter);
(top-gdb) 
std::map with 258866279488 elementsCannot access memory at address 0x18

Basically the Python iterator is failing (because the child is
bogus/uninitialized). This happens in both mi and cli cases. 

A patch will be forthcoming.

Created attachment 4694 [details]
patch

Draft Patch

The problem I noted on my setup was common_val_print was raising a GDB error()
due to a read at an invalid location.  The function print_children() handles and
clears its own Python exceptions, but this error() call was neither converted or
handled. So this error was propagating as unhandled and the pretty printing
process terminated in the command that called it. So commands like
-stack-list-locals which print large amount of different variables were
terminating prematurely.

This draft patch in #12 fixes it for me, but I am not sure if it is correct. 
Does it work for you? I'd like Tom to have a look at this, hence the CC addition.

(In reply to comment #13)
> Does it work for you?
It definitely improves the situation. But I suspect there are other similar 
situations like the one you found and fixed.
I still need to step over the declaration of
  map<int, string> mappedStrings;
before local variables are returned.

The patch is not right. It is fixing the problem at a level that is "too low",
it can happen with any error raised in these command, regardless whether that
error emanates from python pretty printers.  The python pretty printers just
make this bug happen far more often. I'll look at fixing it universally in the
value printing code.

Created attachment 4769 [details]
non-python backtrace abort reproducer.

Current output is:

#3  0x4afe5437 in func () at dw2-loclist-prelinked.c:8
	i = Could not find the frame base for "func".
<backtrace stop>

while we would expect output like:

#3  0x4afe5437 in func () at dw2-loclist-prelinked.c:8
	i = Could not find the frame base for "func".
	j = Could not find the frame base for "func".
#4  ... continued backtrace

Just the attached code is not suitable, it needs to be sanitized, but it proves
the problem.

Hi, all.
Is there any mechanism that in the debug build, the compiler can generate some
extra code after a local variable is initialized. so that if we want to list the
local variables, only the initialized variables will be shown. If I remember
correct, In C++, if a function is invoked in the "try-exception" block, there
will be a "local variable initialize list" for each function. So, when a
exception happens, the function handling code must check this variable list, and
see which variables were initialized, so that destructor functions will be
called on these kind of objects.

I'm not sure this special structure is exist in the "debug information".

BTW: I have the python pretty printer enabled gdb, when debugging, I always get
gdb crashed when I trying to view the uninitialized local variables. (Windows
XP, and the gdb is built myself)

IT is very important for an IDE like codeblocks. 

Asmwarrior
ollydbg from codeblocks forum

Sorry for interrupt here again.

I personally think that this "debug info about a variable is initialized or not"
should exist in the function which exception handling is enabled. For example:

Quote
try
{

A a;
CallXXX();

B b;
CAllYYY();

}

At this time, the variables info (initialed or not) should be recorded in
somewhere. Because exceptions can happens every where, the exception handler 
need to call the "destruction of the already initialized objects".

I guess there is a table to record this debug info.. So, my question is: Can GDB
read this information?

thanks.

The problem is not specific to Python, this can happen anywhere within GDB. 
Python is good at showing these bugs.  There is, imo, a GDB exception not being
handled correctly somewhere within the value printing code.  It has to be caught
and handled much closer to the exception source that my original patch (posted
here).  I'm working on a patch for this today, so hopefully we might see some
relief from it soon.

Created attachment 4845 [details]
another draft patch

This patch assumes that apply_val_pretty_printer can raise errors.  val_print
is called most commonly in the pretty printers by print_children.  This
function makes n*children calls to PyIter, which usually results in errors
arising from uninitialized data. These errors can come from *anywhere* within
Python.  If the exception is not handled here,	it will bubble up to the top
and GDB will stop executing.  In this patch, I catch the exception and print
the error and attempt to print out the data in raw format.  I guess we could
exit if we wanted to. This fixes the error cases in this bug.  This is draft
patch, what do you think?

(In reply to comment #20)
> Created an attachment (id=4845)
> another draft patch
> 
> This patch assumes that apply_val_pretty_printer can raise errors.  val_print
> is called most commonly in the pretty printers by print_children.  This
> function makes n*children calls to PyIter, which usually results in errors
> arising from uninitialized data. These errors can come from *anywhere* within
> Python.  If the exception is not handled here,	it will bubble up to the top
> and GDB will stop executing.  In this patch, I catch the exception and print
> the error and attempt to print out the data in raw format.  I guess we could
> exit if we wanted to. This fixes the error cases in this bug.  This is draft
> patch, what do you think?

Thanks, I will test this patch as soon as I return to my work place. By the way,
the way you use is try to catch all the exceptions from the python, this way,
gdb are protected. But I'm not sure you have understand my post #18, I said that
is there any "debug infor" that we can get, if one local variable has been
initialized. There is a discussion at Codeblocks' forum

http://forums.codeblocks.org/index.php/topic,12747.msg86349.html#msg86349

I have give an example, that if gcc can add some extra code to indicate that one
local variable is initialized.

Thanks

Asmwarrior ollydbg from codeblocks' forum

(In reply to comment #20)
> Created an attachment (id=4845)
> another draft patch This is draft
> patch, what do you think?

Hi, I have just build a gdb.exe applied your patch, and it seems the gdb.exe
still get crashed when I use "info local" command before some local variable
declaration.

So, My suggestion, I think gdb must understand which local variables were
already initialized, and which are not. Then, "info local" command should only
plot the initialized local variable.

Thanks.
asmwarrior

With the test-case posted here it works.  If you can post me a test-case I will
check against my build.

I do not believe GDB can tell what is initialized and what is not.  That might
be another bug to file.  But in the case here, GDB was missing exceptions
generated and we catch them and deal with them in the pretty-printer case.

It is beginning to sound like we have two bugs here.

I just re-read your comment and you noted GDB "crashed". That was never the
behaviour before.  GDB in this bug never crashes, but just stops supplying
information for that command as a GDB exception was not caught. GDB was (And is,
with my build) still alive and ready to receive other commands.

What build/OS are you using?

(In reply to comment #23)
> With the test-case posted here it works.  If you can post me a test-case I will
> check against my build.
Hi,here is the test code:

#include <string>
#include <map>
#include <list>
#include <stack>
#include <vector>

void test()
{

    std::string stdStr("std::string");
    stdStr.append(" value");
    std::map<int, std::string> m;
    m[0] = "000";
    m[1] = "111";
    std::string& stdStrRef = stdStr;
    stdStrRef += " Ref";

    std::list<std::string> l = {"a", "b", "c"};
    std::vector<std::string> v = {"a", "b", "c"};

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

}

int main()
{
    test();
    return 0;
}

In my system(WindowsXP, gdb build from MinGW 4.4.4, python pretty printer enabled)
When I set a breakpoint before" std::string stdStr("std::string");", then
entered the gdb command "info locals", then gdb crashed.

Here is the log:
Breakpoint 2, test () at E:\code\cb\codeblocks_test_code\gdbpython-demo\main.cpp:11
E:\code\cb\codeblocks_test_code\gdbpython-demo\main.cpp:11:111:beg:0x4013dc
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> info locals
stdStr = 
m = std::map with 4063232 elements<error applying pretty-printer>{
  _M_t = {
    _M_impl = {
      <std::allocator<std::_Rb_tree_node<std::pair<int const,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >> = {
        <__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<int const,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >> =
{<No data fields>}, <No data fields>}, 
      members of std::_Rb_tree<int, std::pair<int const, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<int
const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >
>, std::less<int>, std::allocator<std::pair<int const, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >
>::_Rb_tree_impl<std::less<int>, false>: 
      _M_key_compare = {
        <std::binary_function<int, int, bool>> = {<No data fields>}, <No data
fields>}, 
      _M_header = {
        _M_color = 4072408, 
        _M_parent = 0x40a050, 
        _M_left = 0x22fef0, 
        _M_right = 0x77c2c024
      }, 
      _M_node_count = 4063232
    }
  }
}
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.



> 
> I do not believe GDB can tell what is initialized and what is not.  That might
> be another bug to file.  But in the case here, GDB was missing exceptions
> generated and we catch them and deal with them in the pretty-printer case.
> 
> It is beginning to sound like we have two bugs here.

Created attachment 4853 [details]
Output from patch

I get different results, GDB behaves as expected (Does not crash, abandons
pretty printing for that local, prints the rest of the local out in raw format,
moves onto the next local)

I built your inferior with 

g++ -g3 -std=c++0x repr2.cpp -o repr2

I see over on the libstdc++ list there might be differences in your compiler. 
In any case, this looks like a mingw issue? Might need to split up this bug.

(In reply to comment #26)
> Created an attachment (id=4853)
> Output from patch
> 
> I get different results, GDB behaves as expected (Does not crash, abandons
> pretty printing for that local, prints the rest of the local out in raw format,
> moves onto the next local)
> 
> I built your inferior with 
> 
> g++ -g3 -std=c++0x repr2.cpp -o repr2
> 
> I see over on the libstdc++ list there might be differences in your compiler. 
> In any case, this looks like a mingw issue? Might need to split up this bug.

Hi, thanks for your test.

I found that if I set the breakpoint in the line 11, the same as you, then run
info locals command
gdb.exe( 20100613cvs ), works
gdb.exe( 20100618cvs with your patch), gdb crash.

But if I run "info locals" in very line of my code, none of gdb can survive.
(Both of the gdb.exe will get crashes on some lines)

As you said, GDB under Windows are not stable as on linux. 

Hi, I would like to say something about the local variable.
Today, I just read the Dwarf-2's standard PDF, 
http://dwarfstd.org/doc/dwarf-2.0.0.pdf
then I found that for a local variable, it has a property named" scope".
You can see it in the page 36 of that PDF. And in that page, there is an example
code:

float x = 99.99;
int myfunc()
{
float f = x;
float x = 88.99;
return 0;
}

Then, the PDF said: 
ANSI-C scoping rules require that the value of the variable x assigned to the
variable f in the initialization sequence is the value of the global variable x,
rather than the local x,because the scope of the local variable x only starts
after the full declarator for the local x.

So, here comes my idea: If we breakpoint stops in the line:
float f = x;
That means, we are "out of the scope of local variable x". Can gdb find this
property of the local x, at the same time, when people run: info locals command.

GDB should firstly check all the locals, then only list the locals' scope is
cover the current PC, by this, we can safely run the python script.(because all
the variables involved must be initialized" already)

I'm not sure you can understand my idea. Sorry, I'm not familiar with the source
of GDB. Correct me if I'm totally wrong.

Thanks

Asmwarrior ollydbg from codeblocks' forum

A deeper search, I found that the DW_AT_start_scope information for a local
variable was not emitted by GCC. So, GDB has no way to get these information.

You can see
http://gcc.gnu.org/ml/gcc/2007-04/msg00139.html

I'm not sure it can be added in GCC easily.

Asmwrrior

Some one from GCC maillist has suggestion me to use -fvar-tracking in the GCC
command options, see

http://gcc.gnu.org/ml/gcc/2010-06/msg00633.html

From the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

-fvar-tracking
    Run variable tracking pass. It computes where variables are stored at each
position in code. Better debugging information is then generated (if the
debugging information format supports this information).
    It is enabled by default when compiling with optimization (-Os, -O, -O2,
...), debugging information (-g) and the debug info format supports it. 

So, is it possible that GDB get this information?

I'm not sure, but it is unlikely to get any traction or viewing here.  This bug
has been raised to deal with uncaught exceptions being generated because the
data is uninitialized and the pretty-printers are not coping.  While I don't
necessarily disagree with anything you have proposed, I'm not likely the person
to be involved in those deeper architectural changes ;) I purely hack on the
Python aspects.

The architectural changes you propose for GDB are unlikely to reach your target
audience in the bug.  I would try gdb@ mailing list.

@all
I have solved "uninitialized local variable" problem by change the code of GDB
source. 

You can see the screen shot of my result (I tested under Codeblocks WindowsXP)

http://i683.photobucket.com/albums/vv194/ollydbg_cb/one_variable.png
and
http://i683.photobucket.com/albums/vv194/ollydbg_cb/two_variable-1.png

I will soon publish my patch here.

Hi, here is my modified source code of gdb/stack.c
it is around the line 1469, and then change the function to like this below:
-------------------------

static void
iterate_over_block_locals (struct block *b,
               iterate_over_block_arg_local_vars_cb cb,
               void *cb_data)
{
  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)
    {
      switch (SYMBOL_CLASS (sym))
    {
    case LOC_LOCAL:
    case LOC_REGISTER:
    case LOC_STATIC:
    case LOC_COMPUTED:
      if (SYMBOL_IS_ARGUMENT (sym))
        break;
      if(sym->line>= sal.line)
        break;
      (*cb) (SYMBOL_PRINT_NAME (sym), sym, cb_data);
      break;

    default:
      /* Ignore symbols which are not locals.  */
      break;
    }
    }
} 

---------------------------------

Asmwarrior ollydbg from codeblocks' forum

Please try to get a stack trace of gdb at the time of the crash.
GDB should not crash in this circumstance.  That is the bug here.
I think all the stuff about scoping is a distraction; you can still
see strange variable values due to bugs or whatnot; gdb has to
be robust against that.  

Subject: Bug 11407

CVSROOT:	/cvs/src
Module name:	src
Changes by:	jkratoch@sourceware.org	2010-06-25 15:34:46

Modified files:
	gdb/testsuite  : ChangeLog 
	gdb/testsuite/gdb.dwarf2: dw2-ref-missing-frame-main.c 
	                          dw2-ref-missing-frame.S 
	                          dw2-ref-missing-frame.exp 
Added files:
	gdb/testsuite/gdb.dwarf2: dw2-ref-missing-frame-func.c 

Log message:
	gdb/testsuite/
	Test PR python/11407.
	* gdb.dwarf2/dw2-ref-missing-frame-func.c: New file.
	* gdb.dwarf2/dw2-ref-missing-frame.S: Use cu_text_start and cu_text_end.
	Split main into func_nofb and func_loopfb dropping NO_FRAME_BASE.
	* gdb.dwarf2/dw2-ref-missing-frame.exp: Remove variables sources,
	executable_nofb and executable_fb.  New variables srcsfile, objsfile,
	srcfuncfile, objfuncfile, srcmainfile, objmainfile, executable and
	binfile.  Call gdb_compile with clean_restart twice.
	(func_nofb print, func_nofb backtrace, func_loopfb print)
	(func_loopfb backtrace): New.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2350&r2=1.2351
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame-func.c.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame-main.c.diff?cvsroot=src&r1=1.1&r2=1.2
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame.S.diff?cvsroot=src&r1=1.2&r2=1.3
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame.exp.diff?cvsroot=src&r1=1.4&r2=1.5

A patch was posted for the CLI interpretation of the bug here:

http://sourceware.org/ml/gdb-cvs/2010-06/msg00169.html

A patch for MI is currently being discussed here.  Here is the latest rendition
of tha patch:

http://sourceware.org/ml/gdb-patches/2010-06/msg00599.html

Assigned this bug to MI component.

Subject: Bug 11407

CVSROOT:	/cvs/src
Module name:	src
Changes by:	pmuldoon@sourceware.org	2010-09-16 13:47:55

Modified files:
	gdb            : ChangeLog 
	gdb/mi         : mi-cmd-stack.c 
	gdb/testsuite  : ChangeLog 
Added files:
	gdb/testsuite/gdb.mi: dw2-ref-missing-frame-func.c 
	                      dw2-ref-missing-frame-main.c 
	                      dw2-ref-missing-frame.S 
	                      dw2-ref-missing-frame.exp 

Log message:
	2010-09-16  Phil Muldoon  <pmuldoon@redhat.com>
	
	PR mi/11407
	* mi/mi-cmd-stack.c (list_args_or_locals): Catch exceptions from
	read_var_value and common_val_print and print a warning.
	
	2010-09-16  Phil Muldoon  <pmuldoon@redhat.com>
	Jan Kratochvil  <jan.kratochvil@redhat.com>
	
	PR mi/11407
	* gdb.mi/dw2-ref-missing-frame-func.c: New File.
	* gdb.mi/dw2-ref-missing-frame-main.c New File.
	* gdb.mi/dw2-ref-missing-frame.S New File.
	* gdb.mi/dw2-ref-missing-frame.exp New File.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.12189&r2=1.12190
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/mi/mi-cmd-stack.c.diff?cvsroot=src&r1=1.51&r2=1.52
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2449&r2=1.2450
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame-func.c.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame-main.c.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame.S.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/dw2-ref-missing-frame.exp.diff?cvsroot=src&r1=NONE&r2=1.1

MI fix checked in as per comment #37.  Thanks for your patience!

Set Target to 7.3