| Summary: | Confusing python backtrace on iterator end | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Mark Wielaard <mark> |
| Component: | python | Assignee: | Tom Tromey <tromey> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | tromey |
| Priority: | P2 | ||
| Version: | archer | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
This works better with cvs head. I will post some more details tomorrow; I'm not totally sure whether some of my local patches improve this or not. With cvs head gdb I get:
(gdb) p it
$1 = {
first =
<error reading variable: Cannot access memory at address 0xfffffff5>,
second = {
a = 134524960,
b = 1
}
}
I think that seems a lot more reasonable.
(In reply to comment #2) > With cvs head gdb I get: > > (gdb) p it > $1 = { > first = > <error reading variable: Cannot access memory at address 0xfffffff5>, > second = { > a = 134524960, > b = 1 > } > } > > I think that seems a lot more reasonable. Yes, much more reasonable, thanks. Although I think it is still a but too verbose. Ideally (for me) the default would just have a short indicator (say "<???>") that tells me the value couldn't be determined. Then if I would like to see why that is (p /v maybe) it would display all the extra explanations. |
Take the following silly example: #include <map> #include <string> struct foo { int a; int b; }; int main(int argc, char **argv) { std::map<std::string, foo> map; foo f = { 1, 2 }; map.insert (std::pair<std::string, foo> ("first", f)); std::map<std::string, foo>::iterator it = map.begin (); it++; return 0; } GNU gdb (GDB) Fedora (7.2-26.fc14) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/foo...done. (gdb) break main Breakpoint 1 at 0x400b5d: file foo.cpp, line 12. (gdb) n The program is not being run. (gdb) r Starting program: /tmp/foo Breakpoint 1, main (argc=1, argv=0x7fffffffe278) at foo.cpp:12 12 std::map<std::string, foo> map; (gdb) n 14 foo f = { 1, 2 }; (gdb) n 15 map.insert (std::pair<std::string, foo> ("first", f)); (gdb) n 17 std::map<std::string, foo>::iterator it = map.begin (); (gdb) n 18 it++; (gdb) p it $1 = {first = "first", second = {a = 1, b = 2}} (gdb) n 20 return 0; (gdb) p it $2 = {first = Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 549, in to_string return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) RuntimeError: Cannot access memory at address 0xffffffffffffffe9 , second = {a = -7944, b = 32767}} It isn't so much surprising that the printing fails, since we are now at it == map.end(). But you might see this sometimes when you forgot, or when taking an iterator when a map is empty so map.begin () == map.end (). It would be nice to not get that RuntimeError and partial python backtrace. It doesn't really add any information, except that the string couldn't be shown. Ideally it would detect the iterator ran out and just report that. If that isn't possible then please don't print these internal python printer errors that are just confusing and don't add any useful information.