rust-gdb mishandles very long vectors

[huonw]

It appears to try to print/handle all elements of a vector, which means it eats a ton of CPU and memory for a very long one. This includes vectors that have been moved from, which have their length field filled in with 0x1d1d...... which is a very large length (it can also occur when trying to debug memory corruption/mistakes: corrupting the length field may make it harder to use the debugger).

fn main() {
    let mut v = Vec::<u32>::new();
    std::mem::forget(v);
}

$ rustc extralong.rs -g
$ rust-gdb ./extralong
...
(gdb) break 4
Breakpoint 1 at 0x48bf: file extralong.rs, line 4.
(gdb) r
Starting program: /home/huon/projects/test-rust/extralong 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, extralong::main () at extralong.rs:4
4   }
(gdb) p v
^CPython Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>: 
$1 = Vec<u32>(len: 2097865012304223517, cap: 2097865012304223517)
(gdb) p/x v.len 
$2 = 0x1d1d1d1d1d1d1d1d
(gdb)

(note the ^C to cancel the p v.)

[michaelwoerister]

Good catch. That should definitely be handled better.

[draivin]

As a note, when trying the gdb pretty-printers on windows, whenever I execute info locals on a scope which contains a Vec that has not been declared yet, the uninitialized len is a large number, and the pretty printer will try printing the vector, causing the same error.

[michaelwoerister]

Fixed by #34639