realgcc.exe "no disk in the drive" error on windows

eriknstevenson commented 8 years ago

Overview

Recently I've run into a pretty annoying issue that's currently preventing me from operating stack on my windows tower.

While running stack setup or stack build I am greeted with the following error:

Regardless of what button I click on the message box, the error continues to pop until I terminate the processes for ghc.exe, gcc.exe, realgcc.exe, and the command prompt.

I'm curious if anyone else has run into this at all, and realize this may be a ghc issue instead of a stack issue. Why it's attempting to do anything with my D:\ drive at all is just absolutely baffling and frustrating.

Attempted resolutions

multiple resolvers
uninstalling/reinstalling stack
Obligatory console logs

stack --version output

C:\Users\erik>stack --version
Version 1.0.2, Git revision fa09a980d8bb3df88b2a9193cd9bf84cc6c419b3 (3084 commits) x86_64

`stack setup --verbose` output (up until the point where it freezes and the error is displayed):

C:\Users\erik>stack setup --verbose
Version 1.0.2, Git revision fa09a980d8bb3df88b2a9193cd9bf84cc6c419b3 (3084 commits) x86_64
2016-02-16 20:05:04.474280: [debug] Checking for project config at: C:\Users\erik\stack.yaml @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:660:9)
2016-02-16 20:05:04.475737: [debug] Checking for project config at: C:\Users\stack.yaml @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:660:9)
2016-02-16 20:05:04.475737: [debug] Checking for project config at: C:\stack.yaml @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:660:9)
2016-02-16 20:05:04.476252: [debug] No project config file found, using defaults. @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:687:13)
2016-02-16 20:05:04.477240: [info] Run from outside a project, using implicit global project config @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:405:13)
2016-02-16 20:05:04.477741: [info] Using resolver: lts-5.1 from implicit global project's config file: C:\Users\erik\AppData\Roaming\local\bin\global-project\stack.yaml @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:419:32)
2016-02-16 20:05:04.478257: [debug] Trying to decode C:\Users\erik\AppData\Roaming\local\bin\build-plan-cache\x86_64-windows\lts-5.1.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-02-16 20:05:04.493251: [debug] Success decoding C:\Users\erik\AppData\Roaming\local\bin\build-plan-cache\x86_64-windows\lts-5.1.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-02-16 20:05:04.494278: [debug] Trying to decode C:\Users\erik\AppData\Roaming\local\bin\indices\Hackage\00-index.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-02-16 20:05:04.703730: [debug] Success decoding C:\Users\erik\AppData\Roaming\local\bin\indices\Hackage\00-index.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-02-16 20:05:04.717637: [debug] Performing a sanity check on: C:\Users\erik\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\bin\ghc.exe @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Setup src/Stack\Setup.hs:1294:5)
2016-02-16 20:05:04.718134: [debug] Run process: ghc C:\Users\erik\AppData\Local\Temp\stack-sanity-check11028\Main.hs -no-user-package-db @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)

`stack build --verbose` output (up until the point where it freezes and the error is displayed)

C:\Users\erik\narrative.github.io>stack build --verbose
Version 1.0.2, Git revision fa09a980d8bb3df88b2a9193cd9bf84cc6c419b3 (3084 commits) x86_64
2016-02-16 20:33:05.993953: [debug] Checking for project config at: C:\Users\erik\narrative.github.io\stack.yaml @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:660:9)
2016-02-16 20:33:05.994538: [debug] Loading project config file stack.yaml @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Config src/Stack\Config.hs:683:13)
2016-02-16 20:33:05.996240: [debug] Trying to decode C:\Users\erik\AppData\Roaming\local\bin\build-plan-cache\x86_64-windows\lts-5.3.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-02-16 20:33:06.010468: [debug] Success decoding C:\Users\erik\AppData\Roaming\local\bin\build-plan-cache\x86_64-windows\lts-5.3.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-02-16 20:33:06.010955: [debug] Trying to decode C:\Users\erik\AppData\Roaming\local\bin\indices\Hackage\00-index.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-02-16 20:33:06.215687: [debug] Success decoding C:\Users\erik\AppData\Roaming\local\bin\indices\Hackage\00-index.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-02-16 20:33:06.228253: [debug] Run process: ghc --numeric-version @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)
2016-02-16 20:33:06.243786: [debug] Run process: ghc-pkg --no-user-package-db field --simple-output Cabal version @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)
2016-02-16 20:33:06.293266: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)
2016-02-16 20:33:06.344708: [debug] Checking resolver: lts-5.3 @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Build.Source src/Stack\Build\Source.hs:164:17)
2016-02-16 20:33:06.344708: [debug] Trying to decode C:\Users\erik\AppData\Roaming\local\bin\build-plan-cache\x86_64-windows\lts-5.3.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-02-16 20:33:06.352748: [debug] Success decoding C:\Users\erik\AppData\Roaming\local\bin\build-plan-cache\x86_64-windows\lts-5.3.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-02-16 20:33:06.355909: [debug] Run process: ghc-pkg --global --no-user-package-db dump --expand-pkgroot @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)
2016-02-16 20:33:06.419353: [debug] Ignoring package haskeline due to wanting version 0.7.2.2 instead of 0.7.2.1 @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Build.Installed src/Stack\Build\Installed.hs:189:5)
2016-02-16 20:33:06.419854: [debug] Ignoring package Cabal due to wanting version 1.22.7.0 instead of 1.22.5.0 @(stack_17sBDK7EAGnHgWa8uDWGI4:Stack.Build.Installed src/Stack\Build\Installed.hs:189:5)
2016-02-16 20:33:06.420354: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db C:\Users\erik\AppData\Roaming\local\bin\snapshots\f97b84a6\pkgdb dump --expand-pkgroot @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)
2016-02-16 20:33:06.471063: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db C:\Users\erik\narrative.github.io\.stack-work\install\03c0d273\pkgdb dump --expand-pkgroot @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Read src/System\Process\Read.hs:269:3)
2016-02-16 20:33:06.522422: [debug] Trying to decode C:\Users\erik\AppData\Roaming\local\bin\indices\Hackage\00-index.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-02-16 20:33:06.708882: [debug] Success decoding C:\Users\erik\AppData\Roaming\local\bin\indices\Hackage\00-index.cache @(stack_17sBDK7EAGnHgWa8uDWGI4:Data.Binary.VersionTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-02-16 20:33:06.953057: [debug] Run process: C:\Users\erik\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\bin\ghc.exe -clear-package-db -global-package-db -hide-all-packages -package base -package Cabal-1.22.5.0 C:\Users\erik\AppData\Local\Temp\stack7784\Setup.hs -o C:\Users\erik\AppData\Roaming\local\bin\setup-exe-cache\x86_64-windows\tmp-setup-Simple-Cabal-1.22.5.0-ghc-7.10.3.exe @(stack_17sBDK7EAGnHgWa8uDWGI4:System.Process.Run src/System\Process\Run.hs:105:5)
[1 of 1] Compiling Main             ( C:\Users\erik\AppData\Local\Temp\stack7784\Setup.hs, C:\Users\erik\AppData\Local\Temp\stack7784\Setup.o )

my system info

I'm be happy to provide any other information which may be useful, just ask. Thanks.

mgsloan commented 8 years ago

Huh, googling for this error and realgcc reveals nothing. stack --verbose --cabal-verbose might be helpful info.

This discussion could possibly be relevant: https://github.com/commercialhaskell/stack/issues/466

eriknstevenson commented 8 years ago

No longer experiencing this on a fresh install of windows. Still no idea what the root cause was, but I guess it was isolated to my machine. Hopefully it won't pop up again. Feel free to close the issue.

mgsloan commented 8 years ago

Cool, glad the issue is resolved, thanks for following up!

eriknstevenson commented 8 years ago

This actually started occurring again last night out of the blue. On a hunch, I tried switching from Command Prompt to PowerShell and it seems to have gone away.

This issue is fine staying closed I think, but just wanted to throw this out there for anyone that might run into this in the future.

alejoteijo commented 8 years ago

Same issue,

eriknstevenson commented 8 years ago

Hey sorry to hear that. Here are two things I'd recommend trying:

Use PowerShell instead of Command Prompt.
In Device Manager, disable the disk drive(s) that realgcc.exe is attempting to access.

mudont commented 8 years ago

I had the same issue. Google led me here. Thanks narrative. Powershell was the solution.

sboosali commented 8 years ago

Same issue. Only errors when my external microphone is plugged in.

Settings:

Windows 10 Pro 64-bit
Samsung E-series 900X4C

>stack --version
Version 1.2.0 x86_64 hpack-0.14.0

DrEntropy commented 8 years ago

Same issue here, windows 10 64 bit. Basically, windows is the worst. realgcc.exe should not be checking all the drives though?

araybold commented 7 years ago

Same for me - a new, never-been-installed before installation on Windows 10 Pro version 1607 build 14393.447 64-bit.

Not only does it put up this message, but it will not quit. If I kill realgcc.exe in task manager it restarts like some malware. There is nothing in D: now and there was nothing in D: when I installed it - so why is it even looking there? Re Dr. Entropy's comment, I am not at all convinced the fault is with Windows in this case.

Bellarmine-Head commented 7 years ago

Same for me on Windows 8.1. My first attempt to install Stack / Haskell. It failed with this problem. I didn't try the PowerShell solution... just uninstalled Stack and the compiler(s) it had attempted to install, and walked away. I figured that unless it "just works", I'm going to be fighting endless silly problems forever on Windows.

GarryGelade commented 7 years ago

Same issue for me. Tried to install the Haskell core x64 version 8.02 on Windows 10. realgcc tries to access Drive D, and I had to shut it down in Task Manager. Not a good omen for Haskell.

GarryGelade commented 7 years ago

Uninstalled Haskell and reinstalled it using PowerShell. Then shut down and restarted the PC to ensure system files are updated. This seems better - at least I can open WinGHCi now, although I don't know if its all working yet. Thanks to those who suggested PowerShell.

seestevecode commented 7 years ago

I'm also getting this issue on Win 10. It was fine on Win 8.1 before I got a new PC. I'm not familiar with PowerShell. Can someone direct me to how I can try to reinstall Haskell Platform using that, please? Thank you.

Mistuke commented 7 years ago

Can anyone who has this issue run strace and post the output? e.g. strace gcc helloworld.hs.

Mistuke commented 7 years ago

These two issues seem to be related https://sourceforge.net/p/mingw/bugs/2108/ and https://superuser.com/questions/836250/there-is-no-disk-in-the-drive-please-insert-a-disk-into-drive-e It seems like it's a bug in the gcc bindist that we distribute.

The GCC bug is https://ghc.haskell.org/trac/ghc/ticket/13400 and I'll open one for MinGW-w64 shortly.

Mistuke commented 7 years ago

Can someone with this issue paste the output of realgcc -v ? I'm having trouble reproducing this.

Bellarmine-Head commented 7 years ago

@Mistuke - I have reproduced this just now using Stack 1.4.0, having:-

Run the Windows installer
run stack install and then, when it said that it couldn't find ghc, I ran stack setup (in the console).

Currently I can't find the strace and realgcc commands. stack setup is still running. I have the dialog box that can't be closed. Do you want me to kill the stack setup session?

BTW: the console window behind the dialog box is saying "This is first start of MSYS2. You MUST restart shell to apply necessary actions.", but currently I can't do anything without dealing with this on-top-of-every-window modal dialog box that says "There is no disk in the drive. Please insert a disk into drive D:". The problem with killing the command window (and this dialog) is that it will prematurely kill the stack setup session.

Mistuke commented 7 years ago

@Andrew-Webb yes you can kill it. Unfortunately this looks like it's being caused by some hard coded references to a D:\ drive in the GCC that was built. The drive isn't actually used, but it's checked anyway.

The easiest way to work around this is by changing the drive letter for the removable drive to something other than D:\. This will have to be fixed upstream, but it's too late for GHC 8.2.1, if there's an 8.2.2 I'll make sure a fix is included.

Bellarmine-Head commented 7 years ago

@Mistuke: it's killed. Not having much luck finding the two programs you mentioned, even though realgcc was the one that was producing the modal dialog box of doom. Any ideas?

Anything else you'd like me to try?

Mistuke commented 7 years ago

@Andrew-Webb no, it's ok. Found the issue. It seems that the GCC in GHC 8.0.1 and GHC 8.0.2 were built on a path D:\develop. This path ended up being hard coded into the binary and it's checked when compiling things.

This results in the following access:

Because of this, you guys with D:\ mapped to a removable drive get the dialog. This is a bit out of our control. But it seems that the GCC that will be used for the upcoming GHC 8.2 release uses C:\building. Since in 99% of the cases everyone has a fixed drive on C:\ if it's available, then it should work.

So for now, I can recommend a workaround of changing the removable storage from D:\ to something else, or wait for GHC 8.2.1.

Bellarmine-Head commented 7 years ago

@Mistuke - thanks for your efforts. Well done.

tallpeak commented 7 years ago

Workaround: DISKPART or DISKMGMT.MSC can be used to reassign D: (CDROM/DVD in my case) to another letter. Eg: Diskpart select volume D assign letter=w see: https://www.howtogeek.com/197296/how-to-use-the-diskpart-utility-to-assign-and-remove-drive-letters/

Here's my output from realgcc -v : C:>realgcc -v Using built-in specs. COLLECT_GCC=realgcc COLLECT_LTO_WRAPPER=C:/PROGRA~1/HASKEL~1/80460E~1.2/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-5.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/5.2.0 --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable -libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv -- with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 5.2.0 (Rev3, Built by MSYS2 project)

ScottFreeCode commented 7 years ago

Ran into this today when I was testing out the ability to use Stack's "script interpreter" mode to deploy shell scripts written in Haskell (wanted to confirm which shell-like libraries, e.g. Turtle and Shelly, are cross-platform). Have a few questions...

Is there a way to be notified when this is fixed?
Will the fix also resolve older versions of GHC that may be used with older packages via Stack?
Is there a way for the Stack configuration in the "script" comment to override which GCC is used so as to work around this issue, without breaking Linux or Mac usage on the other hand?

Mistuke commented 7 years ago

It's as fixed as it's going to get.. GCC 8.2.1 should already have contained a reconfigured GCC. GCC needs to have a root directory, so it uses the directory it gets at configure/build time.

We don't control the GCC distros, but the issue was happening if you have a removable drive which has the same drive letter as one where GCC was configured when the bindist was build. Usually the mingw-w64 people use the C: drive for this, but a build was incorrectly made using the D: drive.

If you have this problem changing your drive letter mappings is the only solution. We won't respin older GHCs since we won't have "fixed" GCCs for them.

ScottFreeCode commented 7 years ago

Hmm... I don't suppose there's any possibility for me to set up automatic hot-patching (a la sed /D:/C:/g)? Or, do we know what the first affected version of GHC is so I could just whitelist a larger range than >= 8.2.1 (e.g. >= 8.2.1 OR < 8.0.0)?

I'm comfortable remapping drive letters on Windows (and distributing binaries after compiling them on a system so remapped), but for comparison I'm also comfortable using sudo dd on disc images; I'm not comfortable sharing affected scripts or projects with Windows developers, however, because:

The D drive is the machine's builtin DVD player (a perfect removable-content yet present-when-empty device to trigger this issue) on every Windows machine I've ever seen, so I can't hope they won't run into the issue.
Windows as far as I can tell considers drive letters to be part of partition management, such that:
- Remapping them requires admin permissions, and
- Remapping them requires tools that could render the system unusable.

Basically, I get that this ultimately comes from GCC's use of the build root rather than the current environment root, but I'm also not going to be the guy to blame if Windows developers screw up when trying to monkey with their drives, so I want to be absolutely certain there isn't something else I could do for them or recommend they do if I want to introduce them to Haskell and the libraries I'm using don't just happen to be up to date for the latest GHC version -- I appreciate that you've done what little you can, I just also would be willing to take a little trouble working around it or even hacking around it on my end.

(By the way, regardless of how it works out, thanks for your help!)

Mistuke commented 7 years ago

do we know what the first affected version of GHC is so I could just whitelist a larger range than

The affected versions are all of the GHC 8.0.x releases. The issue is the GCC 5.2 they ship with. We usually don't change GCC versions for point releases. Any GHC before and after are fine.

I just also would be willing to take a little trouble working around it or even hacking around it on my end.

I spent some more time looking at this today, and it's not something that can be overwritten by specs files, since it's literally baked into the executable. before the specs are processed this list is validated and filtered. It's this process that's triggering the dialog.

I don't suppose there's any possibility for me to set up automatic hot-patching (a la sed /D:/C:/g)?

I won't be that simple, but it is possible. The strings are all in the .rdata section of the executable. and you don't need the paths to exists, just the drive not to be D:. So you can do binary patching of realgcc.exe replacing the 4 D bytes with C.

Attached is a binary xdelta3 patch which would do the trick: gcc_rdata.zip

I don't know if stack has a post-install hook or something, if I does it would be trivial to patch. You could also use the Windows delta compression API that Windows updates uses if you want to avoid a third party patch exe.

(By the way, regardless of how it works out, thanks for your help!)

No problem, we didn't catch this before the release (it's also hard to check for) or we could have done more against it. But with 8.4 coming soon I don't think there's much chance of another 8.0 release...

ScottFreeCode commented 7 years ago

Oooo! The patch approach sounds promising. Very promising in combination with something I figured out today, in fact. :grinning: (Hmm, that emoji makes me look a little maniacal. Well I feel a little maniacal tackling this, so maybe that's fitting?)

I double-checked, and the (possibly minor) bad news I have is that I can get the same behavior with GHC 7.10.3, so it does go back at least a little farther. Depending on how the patch solution plays out in practice I may or may not have to care how far back, though, so this is potentially negligible.

The good news -- besides that I was able to verify it's fixed in 8.2.1 -- is that I figured out it isn't actually tied to the drive being empty, as my initial experiments seemed to show. I'd forgotten to try rebooting (not sure how I forgot that, but oh well, now we know). The issue is actually some other inconsistent state that -- at least in my case -- occurs after there was something in the drive and it was removed (I coincidentally ejected an unrelated DVD before experimenting with Stack yesterday) but only lasts until the next time the system is started up. Or in short, my variation only happens if you've removed a disc since you last booted. So from that I'd infer:

It's some kind of drive state cleanup problem rather than an issue with the more general/normal condition that the drive is empty, therefore probably either a Windows bug or a device driver bug. (I suppose I could look around for a Microsoft bug report on this issue, but I dunno that the probability of finding one justifies the improbability of it making a difference. Unless I just happen to not have the OS patch that fixes it. Hmm...)
It's not going to affect developers who never use DVDs on their development boxes. I don't know if that's most developers, but it's probably at least a statistically significant portion.
When it does affect developers, it is unlikely to be immediate. (It was immediate for me only by coincidence.) In terms of surprise this may be worse -- they could use it for months and then have no idea what changed when they run into this situation -- but...
Most importantly, that means in the event we can't find a good place to automatically run the patching, it should still be easy to run it manually after initial usage of Stack that would download the compiler (then one just has to remember to run it again each time one ends up with a different < 8.2 compiler), even in script interpreter mode where options like stack setup aren't necessarily applicable.

So I'm feeling very confident about being able to manage this! Will experiment with the patch and let you know if I come up with anything in particular to make it automatic and/or easier. Thanks again! :+1:

commercialhaskell / stack