-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rust progams hang on windows #1722
Comments
@ssylvan - We've made some simplications and fixes to the scheduler. I cannot reproduce the deadlock on the bots today after a few hours of trying. Can you still reproduce the hang? |
Is there a windows binary somewhere? I don't have a windows dev environment set up. |
Sorry, still hangs. Doesn't appear to be any user-mode code running, it's completely deadlocked. |
ok. thanks for all your help, ssylvan! |
@ssylvan can I ask for some diagnostic information from your machine? For example: OS version, core count, mingw version, etc? Something like the short text report from hwinfo or the advanced system info panel in windows? Additionally, could you try attaching to it with |
Sure. I run Windows 7 Professional SP1. Core i7 2600K (4 cores, 8 threads). I did just remembered that I have msys installed, so I opened up the msys batch file (which I guess approximates a bash terminal?), and ran rustc from there and it worked fine! EDIT: so to clarify, it hangs when you just run rustc.exe normally, but if I do it through msys.bat it seems to work ENDEDIT. I haven't used gdb before, but here's the log of me attempting to get the back traces from all running threads from the hung rustc.exe (just run through the normal windows command prompt): C:\Users\Sebastian\Documents\rust>gdb --pid 14584
warning: (Internal error: pc 0xdf in read in psymtab, but not in symtab.) #3 0x000000e0 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xd7 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xd7 in read in psymtab, but not in symtab.) #3 0x000000d8 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xcf in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xcf in read in psymtab, but not in symtab.) #3 0x000000d0 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xc7 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xc7 in read in psymtab, but not in symtab.) #3 0x000000c8 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xbf in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xbf in read in psymtab, but not in symtab.) #3 0x000000c0 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xaf in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xaf in read in psymtab, but not in symtab.) #3 0x000000b0 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xa3 in read in psymtab, but not in symtab.) #3 0x000000a4 in ?? () No symbol table info available. #4 0x00000000 in ?? () warning: (Internal error: pc 0xeb in read in psymtab, but not in symtab.) warning: (Internal error: pc 0xeb in read in psymtab, but not in symtab.) #3 0x000000ec in ?? () No symbol table info available. #4 0x00000000 in ?? () |
More information (I know what's wrong, and have a workaround)! I logged all the system events for the running application, and it turns out that rustc.exe is attempting to run a bunch of stuff that isn't actually installed by the rust installer. It happens to find e.g. gcc.exe on my system, but that's because I randomly had mingw installed. That's not guaranteed to be the case. More importantly in my case, it tries to find rm.exe and fails, just before the process stops completely. rm.exe is not on the default mingw bin path (but is in a different path, which is included by msys.bat). Adding my c:\MinGW\msys\1.0\bin path to the system path makes it find rm.exe and the problem goes away. Repeat: everything now works, I just had to manually make sure rm.exe was in my path. It would be better if these things used system APIs to handle files instead of trying to call unix utillities in windows... I've saved a log of the system events so you can see what's going on (with stack traces for each event). It's almost 8MB, so be careful what application you open it in... it can take a while to parse :-) |
I wonder why this manifested as hanging instead of failure. |
Ok. Great. I concur we should get away from calling unix utilities as subprocesses. We've been developing on mingw and in the longer term need to switch over to msvc. But this is quite different from a "threads all hang" situation. I'm comfortable closing this and opening a new one for "don't rely on mingw" or such. |
Filed as #1768 , closing this one. |
Shouldn't it at least not hang when it can't find the tool? Should the installer check for all the tools it needs (or install them)? I can imagine lots of people hitting this on windows. |
I agree that there appears to be another underlying problem here besides depending on a toolchain that isn't installed. Something somewhere in the process spawn path must not be doing proper error checks. I opened another bug for it (#1778) |
There's a threading bug in the runtime that seems quite easy to trip for windows windows users (and sometimes the buildbots). Described in #1602 but this bug exists to track it. Symptom is just the compiler hanging. Not good.
The text was updated successfully, but these errors were encountered: