debuginfo/pretty-uninitialized-vec fails with Cannot access memory at address 0x7fffff7fe000

[mati865]

---- [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs stdout ----
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 8003000

error: gdb failed to execute
status: exit code: 1
command: "/usr/bin/gdb" "-quiet" "-batch" "-nx" "-command=/home/mateusz/Projects/rust/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec/pretty-uninitialized-vec.debugger.script"
stdout:
------------------------------------------
GNU gdb (GDB) 8.3
Copyright (C) 2019 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 0x16c4: file /home/mateusz/Projects/rust/rust/src/test/debuginfo/pretty-uninitialized-vec.rs, line 21.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, pretty_uninitialized_vec::main () at /home/mateusz/Projects/rust/rust/src/test/debuginfo/pretty-uninitialized-vec.rs:21
21	    zzz(); // #break
$1 = Vec<i32>(len: 93824992258736, cap: 140737479962624) = {

------------------------------------------
stderr:
------------------------------------------
/home/mateusz/Projects/rust/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec/pretty-uninitialized-vec.debugger.script:10: Error in sourced command file:
Cannot access memory at address 0x7fffff7fe000

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



failures:
    [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs

[xire28]

Related WIP pull request: #60826

[Centril]

I'm getting this when running ./x.py clean && ./x.py test reliably: https://gist.github.com/rust-play/467eb762d03985ed871d1c0c72cbe32d.

[rinon]

This test is also failing for me with GDB 8.3 on Arch. Same error.

As of GDB 8.3, batch mode causes GDB to exit with non-zero exit status if a command failed, per https://www.gnu.org/software/gdb/news/

GDB in batch mode now exits with status 1 if the last executed command failed.

We either need to execute the "failing" command (the print that accesses invalid memory) from python in gdb and ignore the exception thrown, or ignore the return code of gdb for this test.

[pnkfelix]

pre-triage: not certain what priority to assign (tempted to do P-medium). Leaving nominated for dicsussion of priority at T-compiler meeting.

Also, I think I'll nominate #60826 for discussion there too.

[pnkfelix]

topic is too big to handle in triage meeting. Plan is now to allocate steering meeting to topic; see: rust-lang/compiler-team#186

[pnkfelix]

for now, tagging P-high because this is causing pain for T-release. Hopefully we'll figure something out in the aforementioned planning meeting. Removing nomination.

[pnkfelix]

there's a planning meeting scheduled Oct 18th to discuss debuginfo; this will hopefully be addressed as part of that. See rust-lang/compiler-team#186

[pnkfelix]

self-assigning to at least look into this as part of prep work for aforementioned planning meeting.

[mati865]

@pnkfelix I'm confused by E-needs-bisection. AFAIK the issue here is the test is not compatible with more recent GDB versions, could you elaborate?

[Mark-Simulacrum]

I believe the impression in the planning meeting was that a rustc change broke this test -- if it is a GDB version issue we can likely work to fix the test and bump GDB version requirements.

[rinon]

This was definitely a change to GDB that made the test fail. It still does the expected behavior, but GDB now returns a failure return code.

[pnkfelix]

adding @Centril to assignee list to deal with the test suite stuff to T-release. (See also rust-lang/compiler-team#186 )

[pnkfelix]

Of potential interest: This bug does not reproduce for me on a rustc build with debug = true in the config.toml; I have to turn the debug setting back to its default of false to reproduce the problem.