Failure of pretty-huge-vec.rs on nightly bots

[alexcrichton]

On the Linux bots (where these tests passed) the GDB we're running is:

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1

whereas on the nightly bots (slightly different due to build funkiness) the GDB is custom-built and is:

GNU gdb (GDB) 7.11

Unfortunately the test added here is failing on the nightly bot (full logs):

failures:

---- [debuginfo-gdb] debuginfo-gdb/pretty-huge-vec.rs stdout ----
    NOTE: compiletest thinks it is using GDB version 7.11

error: line not found in debugger output: $1 = Vec<u8>(len: 1000000000, cap: 1000000000) = {[...]...}
status: exit code: 0
command: gdb -quiet -batch -nx -command=x86_64-unknown-linux-gnu/test/debuginfo-gdb/pretty-huge-vec.debugger.script
stdout:
------------------------------------------
GNU gdb (GDB) 7.11
Copyright (C) 2016 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0xcac: file /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/tmp/distcheck/rustc-nightly/src/test/debuginfo/pretty-huge-vec.rs, line 38.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, pretty_huge_vec::main () at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/tmp/distcheck/rustc-nightly/src/test/debuginfo/pretty-huge-vec.rs:38
38      zzz(); // #break
$1 = Vec<u8>(len: 1000000000, cap: 1000000000)
$2 = &[u8](len: 1000000000)
A debugging session is active.

    Inferior 1 [process 25786] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

------------------------------------------
stderr:
------------------------------------------
Python Exception <type 'exceptions.MemoryError'> : 
Python Exception <type 'exceptions.MemoryError'> : 

------------------------------------------

thread '[debuginfo-gdb] debuginfo-gdb/pretty-huge-vec.rs' panicked at 'explicit panic', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/tmp/distcheck/rustc-nightly/src/tools/compiletest/src/runtest.rs:2243
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    [debuginfo-gdb] debuginfo-gdb/pretty-huge-vec.rs

test result: FAILED. 100 passed; 1 failed; 3 ignored; 0 measured

Maybe this fix only applies to older GDB versions? Maybe we need to recompile gdb somewhat differently than what we do today?

---

Note that this is a placeholder issue for a PR I'm about to send, if we manage to resolve I'd love to close out quickly!

[dzamlo]

I don't think the issues is with the gdb version. On my machine, where the test pass, I'm using version 7.11.1. I just tested with version 7.11, and the test still pass.

Note, that I have only run the test with make check-stage1-debuginfo-gdb, but I don't think this change anything for this test.

[alexcrichton]

Hm that's unfortunate :(. I wonder if we need to just build our gdb in a different way? Or perhaps connect it to a different python?

[dzamlo]

It looks like the issue is here only if gdb use python 2. I have absolutely no idea why.

The configure option to compile gdb with python 3 is --with-python=/usr/bin/python3

[alexcrichton]

Whoa weird, is there any way we can get python 2 working as well? Or is it just a bug that was fixed with python 3?

[telotortium]

The range function is called in the Python code in several places, including here. Doesn't range allocate an entire list in Python 2? You want to use xrange instead for Python 2. range in Python 3 is lazy, just like xrange in Python 2. You may want to add

if sys.version_info.major >= 3:
    xrange = range

at the top of the file and then use xrange everywhere else.

[dzamlo]

That what I just found out. The solution proposed by @telotortium is the correct one.

[alexcrichton]

Awesome, thanks @telotortium! @dzamlo or @telotortium, want to send a PR?

[dzamlo]

I'll send a PR

[alexcrichton]

Closing in favor of #34662 and #34663 never landed