[Bug python/11407] New: -stack-list-locals should catch python exceptions and return the error per variable

[Bug python/11407] New: -stack-list-locals should catch python exceptions and return the error per variable

[niko dot sams at gmail dot com]

Printing an uninitialized std::map results in an exception like
"Cannot access memory at address 0x6c894ce02464895c"

When calling -stack-list-locals and such an uninitialized std::map is
in scope it fails with this exception.
And this is not so good as there are no locals shown until the map is
initialized.

-stack-list-locals should catch python exceptions and return the error per
variable.

Same issue with -stack-list-arguments, -stack-list-variables and possibly other
commands.

-- 
           Summary: -stack-list-locals should catch python exceptions and
                    return the error per variable
           Product: gdb
           Version: 7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: niko dot sams at gmail dot com
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[niko dot sams at gmail dot com]

------- Additional Comments From niko dot sams at gmail dot com  2010-03-20 20:00 -------
-var-update has the same issue.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[msnkipa at mail dot ru]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msnkipa at mail dot ru


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens dot elmenthaler at
                   |                            |verigy dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-25 09:15 -------
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?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-25 09:32 -------
(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?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-30 15:31 -------
(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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware dot|pmuldoon at redhat dot com
                   |org                         |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-03-31 13:09 -------
Does setting

help maintenance set python print-stack off 

help in this circumstance?


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-31 13:23 -------
(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) 

------- Additional Comments From pmuldoon at redhat dot com  2010-03-31 13:23 -------
Created an attachment (id=4692)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4692&action=view)
Mi errors output

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

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-31 13:23 -------
(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) 

------- Additional Comments From pmuldoon at redhat dot com  2010-03-31 13:23 -------
Created an attachment (id=4692)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4692&action=view)
Mi errors output

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

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-31 13:45 -------
(In reply to comment #7)
> Created an attachment (id=4692)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4692&action=view)
> 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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-03-31 14:47 -------
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?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-03-31 14:58 -------
Created an attachment (id=4693)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4693&action=view)
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

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-03-31 15:12 -------
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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-01 12:39 -------
Created an attachment (id=4694)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4694&action=view)
patch

Draft Patch

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-01 12:40 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[marc at khouzam dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc at khouzam dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jens dot elmenthaler at verigy dot com]

------- Additional Comments From jens dot elmenthaler at verigy dot com  2010-04-07 07:26 -------
(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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jan dot kratochvil at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan dot kratochvil at redhat
                   |                            |dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-07 17:29 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jan dot kratochvil at redhat dot com]

------- Additional Comments From jan dot kratochvil at redhat dot com  2010-05-05 15:56 -------
Created an attachment (id=4769)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4769&action=view)
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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-18 00:25 -------
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


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asmwarrior at gmail dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-18 08:21 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-06-18 08:36 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #4694 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-06-18 10:25 -------
Created an attachment (id=4845)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4845&action=view)
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?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-19 03:23 -------
(In reply to comment #20)
> Created an attachment (id=4845)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4845&action=view)
> 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






-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-19 04:04 -------
(In reply to comment #20)
> Created an attachment (id=4845)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4845&action=view)
> 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



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-06-19 08:10 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-06-19 08:29 -------
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?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-19 08:40 -------
(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
\x1a\x1aE:\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.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-06-19 09:02 -------
Created an attachment (id=4853)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4853&action=view)
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-19 12:34 -------
(In reply to comment #26)
> Created an attachment (id=4853)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4853&action=view)
> 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. 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-20 03:20 -------
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

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-20 06:14 -------
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

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-20 07:10 -------
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?


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-06-20 07:17 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-21 02:29 -------
@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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-06-21 02:42 -------
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



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11407] -stack-list-locals should catch python exceptions and return the error per variable

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-06-21 19:24 -------
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.  

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug mi/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2010-06-25 15:35 -------
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


------- Additional Comments From pmuldoon at redhat dot com  2010-06-28 17:15 -------
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.



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|python                      |mi


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug mi/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2010-09-16 13:48 -------
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


------- Additional Comments From pmuldoon at redhat dot com  2010-09-16 13:50 -------
MI fix checked in as per comment #37.  Thanks for your patience!

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug mi/11407] -stack-list-locals should catch python exceptions and return the error per variable

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-09-16 13:51 -------
Set Target to 7.3

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|7.1                         |7.3


http://sourceware.org/bugzilla/show_bug.cgi?id=11407

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug mi/11407] -stack-list-locals should catch python exceptions and return the error per variable

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11407

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #40 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/11407] -stack-list-locals should catch python exceptions and return the error per variable

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11407

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.