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.