I was explaining the general problem.

As for std::vector, GDB can and does do this now, through python based pretty printers.

That gdb script is completely unnecessary for this now. Most distros ship with gdb + appropriate pretty printers pre-installed, but they are also available in the libstdc++ repo.

See https://sourceware.org/gdb/wiki/STLSupport

If you use this, print on a vector just works, no extra commands or anything needed.

The pretty printers let you print the entire vector, but do they let you access individual elements within the (potentially very large) vector? That's what this blog post is complaining about not being able to do.

Works absolutely fine on my very standard, almost vanilla installation.

Code:

  #include <vector>
  using namespace std;
  int main()
  {
    vector<int> beans;
    beans.resize(5);
    beans[3] = 4;
    beans [4] = 66;
  }

Build command:

  g++ -g 156.cpp

gdb debugging session:

  GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
  SKIPPED OUT WARRANT INFO HERE
  Reading symbols from /badcode/a.out...done.
  (gdb) break 156.cpp:10
  Breakpoint 1 at 0x4008e6: file 156.cpp, line 10.
  (gdb) run
  Starting program: /badcode/a.out

  Breakpoint 1, main () at 156.cpp:10
  10	  beans [4] = 66;
  (gdb) print beans[3]
  $2 = (int &) @0x60401c: 4
  (gdb) print beans[4]
  $3 = (int &) @0x604020: 0

So, I thought the post above me asked a different question, related to printing out vectors in general :) Possibly they didn't mean to, but asking gdb to "p v[0]" is a function call execution of operator[]. As mentioned in the grandparent, this should work fine on a live process, but is harder on a not live one.

It's possible the parent meant "why can't GDB make v[0] do an inspection directly on the structure". The simple answer is: "It can't possibly know what the function call does". So you'd have to teach it, specifically, that std::vector is special, or provide a mechanism to override the native calls with python scripting (IE be able to say "here is a replacement for T &operator[int] on std::vector that is in python, and works without a live process").

GDB actually does real overload resolution (it has to, otherwise in some 'simple' cases, it'd have to ask you 100 questions about what functions you are trying to call), making that strategy more complicated.

If your only mechanism for reproduction is a core dump, yes this is a pain in the ass. But this shouldn't be true, even remotely, since you always have things like gdbserver/etc.