Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mingw-w64: Most debuginfo-gdb tests fail with new GDB 7.11.1 #40184

Closed
petrochenkov opened this issue Mar 1, 2017 · 7 comments
Closed

mingw-w64: Most debuginfo-gdb tests fail with new GDB 7.11.1 #40184

petrochenkov opened this issue Mar 1, 2017 · 7 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows

Comments

@petrochenkov
Copy link
Contributor

If you recently updated mingw version to x86_64-6.3.0-win32-seh-rt_v5-rev1 or just updated packages in MSYS2 you may discover this unpleasant surprise:

running 1 test
test [debuginfo-gdb] debuginfo-gdb\union-smoke.rs ... FAILED

failures:

---- [debuginfo-gdb] debuginfo-gdb\union-smoke.rs stdout ----
        NOTE: compiletest thinks it is using GDB without native rust support
NOTE: compiletest thinks it is using GDB version 7011001

error: line not found in debugger output: $1 = {a = {__0 = 2 '\002', __1 = 2 '\002'}, b = 514}
status: exit code: 0
command: PATH=blahblahblah C:\mingw-w64\x86_64-6.3.0-win32-seh-rt_v5-rev1\mingw64\bin\gdb -quiet -batch -nx -command=C:\msys64\home\we\rust\build\build\x86_64-pc-windows-gnu\test\debuginfo\union-smoke.debugger.script
stdout:
------------------------------------------
GNU gdb (GDB) 7.11.1
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-w64-mingw32".
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 0x40156e: file C:/msys64/home/we/rust\src/test\debuginfo/union-smoke.rs, line 50.
[New Thread 6068.0x12f4]
quit
A debugging session is active.

        Inferior 1 [process 6068] will be killed.

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

------------------------------------------
stderr:
------------------------------------------
warning: SHIMVIEW: ShimInfo(Complete)
Failed to resume program execution (ContinueDebugEvent failed, error 87)

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

or even worse (with MSYS subsystem gdb)

running 1 test
test [debuginfo-gdb] debuginfo-gdb\union-smoke.rs ... FAILED

failures:

---- [debuginfo-gdb] debuginfo-gdb\union-smoke.rs stdout ----
        NOTE: compiletest thinks it is using GDB without native rust support
NOTE: compiletest thinks it is using GDB version 7011001

error: line not found in debugger output: $1 = {a = {__0 = 2 '\002', __1 = 2 '\002'}, b = 514}
status: exit code: 0
command: PATH=blahblahblah C:\msys64\usr\bin\gdb -quiet -batch -nx -command=C:\msys64\home\we\rust\build\build\x86_64-pc-windows-gnu\test\debuginfo\union-smoke.debugger.script
stdout:
------------------------------------------
GNU gdb (GDB) 7.11.1
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-msys".
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 0x40156e: file C:/msys64/home/we/rust\src/test\debuginfo/union-smoke.rs, line 50.
[New Thread 6600.0x19d0]

------------------------------------------
stderr:
------------------------------------------
Warning: /home/we/rust/build/C: No such file or directory.
Warning: /msys64/home/we/rust./src/etc: No such file or directory.
warning: SHIMVIEW: ShimInfo(Complete)
C:\msys64\home\we\rust\build\build\x86_64-pc-windows-gnu\test\debuginfo\union-smoke.debugger.script:9: Error in sourced command file:
No symbol "u" in current context.
Failed to resume program execution (ContinueDebugEvent failed, error 87)

------------------------------------------
@petrochenkov
Copy link
Contributor Author

petrochenkov commented Mar 1, 2017

Workaround:

  • Purge MSYS subsystem's gdb package if it's installed (pacman -R gdb). I'm not sure if its version can be rolled back given that MSYS2 uses Arch Linux's rolling release scheme.
  • Install mingw-w64 with previous version of GDB. x86_64-6.3.0-win32-seh-rt_v5-rev1 -> x86_64-6.2.0-win32-seh-rt_v5-rev1

@petrochenkov petrochenkov added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-windows-gnu Toolchain: GNU, Operating system: Windows labels Mar 1, 2017
@alexcrichton
Copy link
Member

It looks like if the 6.3.0 gdb is run manually it produces the expected output, it's just when called by the build system that it fails as indicated.

@alexcrichton
Copy link
Member

This is specifically caused when the stdin to the gdb process is a pipe, not inherited. I have absolutely no clue why. I've got a patch to fix though that'll go in #40777

@arielb1
Copy link
Contributor

arielb1 commented Mar 26, 2017

There's a cygwin mailing list thread that looks related: https://cygwin.com/ml/cygwin/2016-10/msg00235.html.

@arielb1
Copy link
Contributor

arielb1 commented Mar 26, 2017

From the mailing list:

I've done some investigation, and the problem seems to be that when run from emacs or ddd, the inferior process doesn't end up in it's own process group, but I haven't made any progress on why that is happening.

Anyone with a working pc-windows-gnu environment: can this be fixed by passing CREATE_NEW_CONSOLE or CREATE_NEW_PROCESS_GROUP to the gdb CreateProcess?

alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 27, 2017
It looks like the 6.3.0 MinGW comes with a gdb which has issues (rust-lang#40184) that an
attempted workaround (rust-lang#40777) does not actually fix (rust-lang#40835). The original
motivation for upgradin MinGW was to fix build flakiness (rust-lang#40546) due to newer
builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back
in time and still contains the fix we need.

Closes rust-lang#40835
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 27, 2017
…elb1

appveyor: Downgrade MinGW to 6.2.0

It looks like the 6.3.0 MinGW comes with a gdb which has issues (rust-lang#40184) that an
attempted workaround (rust-lang#40777) does not actually fix (rust-lang#40835). The original
motivation for upgradin MinGW was to fix build flakiness (rust-lang#40546) due to newer
builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back
in time and still contains the fix we need.

Closes rust-lang#40835
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 25, 2017
This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While
investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.

I'm going to optimistically say...

Closes rust-lang#40546
arielb1 pushed a commit to arielb1/rust that referenced this issue Apr 25, 2017
…enkov

appveyor: Upgrade to gcc for mingw 6.3.0

This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While
investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.

I'm going to optimistically say...

Closes rust-lang#40546
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 26, 2017
This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While
investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.

I'm going to optimistically say...

Closes rust-lang#40546
bors added a commit that referenced this issue Apr 26, 2017
appveyor: Upgrade to gcc for mingw 6.3.0

This commit sort of brings back #40777 by upgrading back to 6.3.0. While
investigating #40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for #40184 contained in #40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.

I'm going to optimistically say...

Closes #40546
@petrochenkov
Copy link
Contributor Author

x86_64-7.1.0-posix-seh-rt_v5-rev0 toolchain is still affected.

@petrochenkov
Copy link
Contributor Author

Fixed starting with x86_64-6.4.0-posix-seh-rt_v5-rev0 and x86_64-7.1.0-posix-seh-rt_v5-rev2!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants