Bug 12425 - Confusing python backtrace on iterator end
Summary: Confusing python backtrace on iterator end
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: archer
: P2 normal
Target Milestone: ---
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-21 11:11 UTC by Mark Wielaard
Modified: 2011-01-28 18:35 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2011-01-21 11:11:00 UTC
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.
Comment 1 Tom Tromey 2011-01-25 21:52:25 UTC
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.
Comment 2 Tom Tromey 2011-01-28 17:17:54 UTC
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.
Comment 3 Mark Wielaard 2011-01-28 18:35:34 UTC
(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.