Benign segfault in gdb on windows

[mrmonday]

Updated Description

When running the program under windows below, it segfaults during startup, but you can get pass the startup by continuing. This is counter intuitive and can we avoid it?

Original Description

Running tests using a debugger on Windows fails

When running tests using a debugger on Windows, the program will always segfault.

#[test]
fn test1() {
}

Compile/debug with with:

$ rustc -g --test test.rs
$ gdb test.exe
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 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 "i686-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"...
Reading symbols from test.exe...done.
(gdb) r
Starting program: C:\msys64\home\Administrator\rust\test.exe
[New Thread 3572.0xde4]

Program received signal SIGSEGV, Segmentation fault.
0x76fb0fe8 in ntdll!ZwMapViewOfSection () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x76fb0fe8 in ntdll!ZwMapViewOfSection ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x76fde09e in ntdll!LdrFindEntryForAddress ()
   from C:\Windows\SYSTEM32\ntdll.dll
#2  0x76fdd4d5 in ntdll!RtlGetLastWin32Error ()
   from C:\Windows\SYSTEM32\ntdll.dll
#3  0x74630000 in ?? ()
#4  0x76fdc94b in ntdll!LdrLoadAlternateResourceModuleEx ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x74630000 in ?? ()
#6  0x76fde744 in ntdll!RtlAddressInSectionTable ()
   from C:\Windows\SYSTEM32\ntdll.dll
#7  0x76f7e54c in ntdll!RtlFindMessage () from C:\Windows\SYSTEM32\ntdll.dll
#8  0x74678b94 in KERNELBASE!CreatePrivateNamespaceW ()
   from C:\Windows\SysWOW64\KernelBase.dll
#9  0x74678d26 in KERNELBASE!FormatMessageW ()
   from C:\Windows\SysWOW64\KernelBase.dll
#10 0x00525782 in os::error_string::ha507dd886b60644fNNg ()
#11 0x004bdef9 in io::file::stat::h766868cc50bec571K2c ()
#12 0x004d6840 in io::IoFactory.rtio..IoFactory::fs_stat::h5b0d3b7472a87d2bfte
    ()
#13 0x00538a9c in io::fs::stat::closure.Name$LP$27247$RP$ ()
#14 0x0053896c in rtio::LocalIo$LT$$x27a$GT$::maybe_raise::h12780674083238291362 ()
#15 0x0053801c in io::fs::stat::h8b8912ef65ffabcftHi ()
#16 0x0054533c in io::fs::path..Path::exists::h66a762d184d98103cyj ()
#17 0x0045faa7 in terminfo::searcher::get_dbpath_for_term::h288f0fa692bef1cbBda ()
#18 0x00462dd3 in terminfo::searcher::open::h2ae82e049270bf631ha ()
#19 0x0047621f in terminfo::TerminfoTerminal$LT$T$GT$.Terminal$LT$T$GT$::new::h5615786229128530927 ()
#20 0x00475de0 in stdout::hc17a42264ec14106Tlc ()
#21 0x00407258 in run_tests_console::h24b6ae27a1813eccIBc ()
#22 0x00404c8a in test_main::h15a659ef08df8c8cvtb ()
#23 0x0041113f in test_main_static::hc1b94da25d253b82xwb ()
#24 0x004016b3 in __test::main::h22be631b8cdb6d0dkaa ()
#25 0x004d9cbc in start::closure.Name$LP$8589$RP$ ()
#26 0x005a5e25 in unwind::try::try_fn::hb77d7400c1f6ab7a8zd ()
#27 0x005a72d6 in rust_try ()
#28 0x005a3b67 in unwind::try::h774dd8e128a93adaLxd ()
#29 0x005a38fa in task::Task::run::hbc2bed2f2b2ad1f5bYc ()
#30 0x004d9b85 in start::h6650db14ba16f5228Me ()
#31 0x004d9a21 in lang_start::h7f0ca33914ef8e74sMe ()
#32 0x00401740 in main ()

This is with Windows Server 2012, 64 bit; binaries are 32 bit.

[alexcrichton]

I've often found that segfault to be benign, and if I type c it ends up working ok. Does that work for you?

[mrmonday]

Ok, that does work. I'm used to working on unicies where a segfault is game over. Thank you. I suppose it probably shouldn't be segfaulting, benign or not.

[alexcrichton]

Updated title/description a bit.

[pnkfelix]

P-low, not 1.0.

[vadimcn]

I don't repro this on current master (as of ba39b50), but it could be transient. Given where it faults, I wouldn't be terribly surprised, if this turned out to be another manifestation of #13259

[vadimcn]

Still no-repro. Recommend closing.

[Gankra]

Feel free to open a new issue if you see this again.

[huonw]

Closing, if it pops up again we can reopen.

[tomaka]

I can't repro with gdb either, however I can reproduce with AMD CodeXL, which is a debugger focused on OpenGL. Screenshot.

Note that it used to work until around one or two weeks ago (sorry, I can't be more precise), when suddenly every single Rust project triggered this second-chance exception, even a simple "hello world".

[tomaka]

The 0x77038e19 address is always the same, whatever the program is.