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

"invalid argument" error on windows #1448

Closed
pbethke opened this Issue Nov 28, 2015 · 19 comments

Comments

Projects
None yet
7 participants
@pbethke

pbethke commented Nov 28, 2015

I had dependency problems building my project with global cabal, so i wanted to switch to stack. Whereas I am able to install new packages via cabal-install, stack always fails with the same error.

The system is Windows 8.1 x64 first with haskell platform and stack, later only stack. The error did not change.

Steps to reproduce

  1. Download stack installer and install stack
  2. Create new stack project with stack new
  3. cd into the new project directory
  4. stack setup finishes successfully (both with haskell platform ghc and newly downloaded ghc)
  5. Try stack install cabal-install (or any other package)

Expected:
6. successful build of cabal and other packages

Actual:
6. Get the following error structure:

PS D:\stacktest> stack build
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
[1 of 1] Compiling Main             ( C:\Users\USER\AppData\Local\Temp\stack764\Setup.hs, C:\Users\USER\AppData\Lo
cal\Temp\stack764\Setup.o )
Linking C:\stack_root\setup-exe-cache\tmp-setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe ...
stacktest-0.1.0.0: configure
Configuring stacktest-0.1.0.0...
setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe: fd:4: invalid
argument
setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe: fd:4: hGetContents: invalid argument (invalid byte sequence)

--  While building package stacktest-0.1.0.0 using:
      C:\stack_root\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe --builddir=.stack-work\dis
t\d96ab9d9 configure --with-ghc=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\bin\ghc.exe --wi
th-ghc-pkg=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\bin\ghc-pkg.exe --user --package-db=c
lear --package-db=global --package-db=C:\stack_root\snapshots\cf5cf2bf\pkgdb --package-db=D:\stacktest\.stack-work\insta
ll\2bc429f2\pkgdb --libdir=D:\stacktest\.stack-work\install\2bc429f2\lib --bindir=D:\stacktest\.stack-work\install\2bc42
9f2\bin --datadir=D:\stacktest\.stack-work\install\2bc429f2\share --libexecdir=D:\stacktest\.stack-work\install\2bc429f2
\libexec --sysconfdir=D:\stacktest\.stack-work\install\2bc429f2\etc --docdir=D:\stacktest\.stack-work\install\2bc429f2\d
oc\stacktest-0.1.0.0 --htmldir=D:\stacktest\.stack-work\install\2bc429f2\doc\stacktest-0.1.0.0 --haddockdir=D:\stacktest
\.stack-work\install\2bc429f2\doc\stacktest-0.1.0.0 --dependency=base=base-4.8.1.0-5e8cb96faebe2db97f24c6e11c6070d6 --ex
tra-include-dirs=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include --extra-inc
lude-dirs=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include --extra-lib-dirs=C
:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\lib --extra-lib-dirs=C:\Users\USER
\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib --enable-tests --enable-benchmarks
    Process exited with code: ExitFailure 1
PS D:\stacktest> stack build
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
stacktest-0.1.0.0: configure
Configuring stacktest-0.1.0.0...
setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe: fd:4: invalid
argument
setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe: fd:4: hGetContents: invalid argument (invalid byte sequence)

--  While building package stacktest-0.1.0.0 using:
      C:\stack_root\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe --builddir=.stack-work\dis
t\d96ab9d9 configure --with-ghc=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\bin\ghc.exe --wi
th-ghc-pkg=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\bin\ghc-pkg.exe --user --package-db=c
lear --package-db=global --package-db=C:\stack_root\snapshots\cf5cf2bf\pkgdb --package-db=D:\stacktest\.stack-work\insta
ll\2bc429f2\pkgdb --libdir=D:\stacktest\.stack-work\install\2bc429f2\lib --bindir=D:\stacktest\.stack-work\install\2bc42
9f2\bin --datadir=D:\stacktest\.stack-work\install\2bc429f2\share --libexecdir=D:\stacktest\.stack-work\install\2bc429f2
\libexec --sysconfdir=D:\stacktest\.stack-work\install\2bc429f2\etc --docdir=D:\stacktest\.stack-work\install\2bc429f2\d
oc\stacktest-0.1.0.0 --htmldir=D:\stacktest\.stack-work\install\2bc429f2\doc\stacktest-0.1.0.0 --haddockdir=D:\stacktest
\.stack-work\install\2bc429f2\doc\stacktest-0.1.0.0 --dependency=base=base-4.8.1.0-5e8cb96faebe2db97f24c6e11c6070d6 --ex
tra-include-dirs=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include --extra-inc
lude-dirs=C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include --extra-lib-dirs=C
:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\lib --extra-lib-dirs=C:\Users\USER
\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib --enable-tests --enable-benchmarks
    Process exited with code: ExitFailure 1

I have tried both powershell and cmd, uninstalling haskell platform, manually removing the stack root, ghc and cabal dirs in %APPDATA%. It doesn't change. Someone on the IRC suggested a unicode problem, but i have no idea how to check for that.

@pbethke

This comment has been minimized.

Show comment
Hide comment
@pbethke

pbethke Nov 29, 2015

Oh, that lengthy command C:\stack_root\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe...` doesn't fail if i call it manually. Is it related to that codepage setting?

pbethke commented Nov 29, 2015

Oh, that lengthy command C:\stack_root\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe...` doesn't fail if i call it manually. Is it related to that codepage setting?

@pbethke

This comment has been minimized.

Show comment
Hide comment
@pbethke

pbethke Nov 29, 2015

OK, one more update:
Using the bash some ssh client brought onto my system, I am able to install and build packages again:

  • stack build fails just as before
  • LANG=C.utf-8 stack build works as intended.

pbethke commented Nov 29, 2015

OK, one more update:
Using the bash some ssh client brought onto my system, I am able to install and build packages again:

  • stack build fails just as before
  • LANG=C.utf-8 stack build works as intended.
@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 3, 2016

Collaborator

Did LANG=C.utf-8 resolve the issue, then? Feel free to re-open if not.

Collaborator

mgsloan commented Jan 3, 2016

Did LANG=C.utf-8 resolve the issue, then? Feel free to re-open if not.

@mgsloan mgsloan closed this Jan 3, 2016

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Jan 11, 2016

I have the same issue on windows with

Version 1.0.0, Git revision 3bc26237b5b3c387b8fd564459ea4dd88fd58b30 (2939 commits) x86_64

and while LANG=C.utf-8 stack buid solves the problem it (of course) only works if you are using some kind of bash

I think you can also add this to your environment variables in windows to work but all this feels like workarounds to me - so it would be great if you could look on it again


in case I am just using an outdated version (although I did grab the latest binary just now) - then please feel free to ignore or delete this comment/item

Thank you

CarstenKoenig commented Jan 11, 2016

I have the same issue on windows with

Version 1.0.0, Git revision 3bc26237b5b3c387b8fd564459ea4dd88fd58b30 (2939 commits) x86_64

and while LANG=C.utf-8 stack buid solves the problem it (of course) only works if you are using some kind of bash

I think you can also add this to your environment variables in windows to work but all this feels like workarounds to me - so it would be great if you could look on it again


in case I am just using an outdated version (although I did grab the latest binary just now) - then please feel free to ignore or delete this comment/item

Thank you

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 11, 2016

Collaborator

@borsboom @snoyberg I don't really grok this windows codepage stuff. Is there something that can be done automatically here?

A couple relevant issues from the past, that led to the current codepage stuff: #757 #824

Collaborator

mgsloan commented Jan 11, 2016

@borsboom @snoyberg I don't really grok this windows codepage stuff. Is there something that can be done automatically here?

A couple relevant issues from the past, that led to the current codepage stuff: #757 #824

@user471

This comment has been minimized.

Show comment
Hide comment
@user471

user471 Jan 12, 2016

If cabal doesn't have such problem then what would be the main difference?

user471 commented Jan 12, 2016

If cabal doesn't have such problem then what would be the main difference?

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Jan 19, 2016

Contributor

@CarstenKoenig Can you try stack-1.0.2 with GHC 7.10.3? There have been a number of fixes to the way GHC handles character encoding and so Stack no longer does any of the codepage/locale hacks if it detects that you're using ghc-7.10.3 or later.

If that doesn't help, I'm surprised that LANG has any effect on Windows. Have you tried using set LANG=C.utf-8 in the regular Windows command-prompt rather than in bash?

Contributor

borsboom commented Jan 19, 2016

@CarstenKoenig Can you try stack-1.0.2 with GHC 7.10.3? There have been a number of fixes to the way GHC handles character encoding and so Stack no longer does any of the codepage/locale hacks if it detects that you're using ghc-7.10.3 or later.

If that doesn't help, I'm surprised that LANG has any effect on Windows. Have you tried using set LANG=C.utf-8 in the regular Windows command-prompt rather than in bash?

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Jan 19, 2016

I just tested it with 1.0.2 and indeed it seems to work (even with GHC 7.10.2).
I'm not 100% sure as I set LANG in my environments-variables in windows as a workaround and although I removed it in the prompt with set LANG= I sometimes doubt if it will not somehow reassign it ...

To make it short I removed the environment and will try again once I rebooted my machine tomorrow.


PS: yes set LANG=C.utf-8 did work in the command-prompt and even if you set it in the systems environment-variables.

CarstenKoenig commented Jan 19, 2016

I just tested it with 1.0.2 and indeed it seems to work (even with GHC 7.10.2).
I'm not 100% sure as I set LANG in my environments-variables in windows as a workaround and although I removed it in the prompt with set LANG= I sometimes doubt if it will not somehow reassign it ...

To make it short I removed the environment and will try again once I rebooted my machine tomorrow.


PS: yes set LANG=C.utf-8 did work in the command-prompt and even if you set it in the systems environment-variables.

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Jan 21, 2016

Update: it seems to work for me right now even on GHC 7.10.2 which seems strange (especially as it tells me

Setting codepage to UTF-8 (65001) to ensure correct output from GHC

still)

CarstenKoenig commented Jan 21, 2016

Update: it seems to work for me right now even on GHC 7.10.2 which seems strange (especially as it tells me

Setting codepage to UTF-8 (65001) to ensure correct output from GHC

still)

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Feb 3, 2016

Well sadly the issue is back: if I

 stack install transformers-base

I get

.stack-work\dist\d96ab9d9\build\src\Control\Monad\Base.dump-hi: commitBuffer: invalid argument (invalid character)

this time no setting (tried LANG, LANGUAGE, LC_ALL) helps

CarstenKoenig commented Feb 3, 2016

Well sadly the issue is back: if I

 stack install transformers-base

I get

.stack-work\dist\d96ab9d9\build\src\Control\Monad\Base.dump-hi: commitBuffer: invalid argument (invalid character)

this time no setting (tried LANG, LANGUAGE, LC_ALL) helps

@mgsloan mgsloan changed the title from Stack fails to build anything to "invalid argument" error on windows Feb 4, 2016

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Feb 4, 2016

Collaborator

Interesting. Is there anything unusual about your setup? I'm just wondering why we aren't hearing similar things from other windows users.

Collaborator

mgsloan commented Feb 4, 2016

Interesting. Is there anything unusual about your setup? I'm just wondering why we aren't hearing similar things from other windows users.

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Feb 4, 2016

well that is hard to tell:

  • Windows 10 Enterprise (german)
  • stack --version: Version 1.0.2, Git revision fa09a980d8bb3df88b2a9193cd9bf84cc6c419b3 (3084 commits) x86_64
  • ghc --version: The Glorious Glasgow Haskell Compilation System, version 7.10.2
  • cabal --version: cabal-install version 1.22.6.0 using version 1.22.4.0 of the Cabal library
  • LANG=C.utf8 set in environment (but tried to remove it too)

The error happened first in the middle of building a project using yesod-hello-world - at least 20 dependencies build without any problems. But as I said a direct call to stack install transformer-base (after the first stack build) always get's me the error too.

And maybe this is why you don't hear that much - if it only happens with certain packages in the middle of a big pile of other packages(?)

CarstenKoenig commented Feb 4, 2016

well that is hard to tell:

  • Windows 10 Enterprise (german)
  • stack --version: Version 1.0.2, Git revision fa09a980d8bb3df88b2a9193cd9bf84cc6c419b3 (3084 commits) x86_64
  • ghc --version: The Glorious Glasgow Haskell Compilation System, version 7.10.2
  • cabal --version: cabal-install version 1.22.6.0 using version 1.22.4.0 of the Cabal library
  • LANG=C.utf8 set in environment (but tried to remove it too)

The error happened first in the middle of building a project using yesod-hello-world - at least 20 dependencies build without any problems. But as I said a direct call to stack install transformer-base (after the first stack build) always get's me the error too.

And maybe this is why you don't hear that much - if it only happens with certain packages in the middle of a big pile of other packages(?)

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Mar 14, 2016

it's still there with stack 1.0.4 (while building ghcjs) - I tried:

  • set all of LC_ALL, LANGUAGE, LANG to C.utf8, de_DE.utf8 or en_US.utf8
  • in the common windows-command-prompt
  • using stack inside git-bash (with the settings above)
  • setting the codepage with chcp 65001 (command-prompt)

nothing works at the moment

CarstenKoenig commented Mar 14, 2016

it's still there with stack 1.0.4 (while building ghcjs) - I tried:

  • set all of LC_ALL, LANGUAGE, LANG to C.utf8, de_DE.utf8 or en_US.utf8
  • in the common windows-command-prompt
  • using stack inside git-bash (with the settings above)
  • setting the codepage with chcp 65001 (command-prompt)

nothing works at the moment

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Mar 14, 2016

Collaborator

I'm not familiar enough with this issue / windows to be much help, sorry! One wild guess is to try temporarily switching the locale to english? That would at least tell us if it's some sort of issue related to locale

Collaborator

mgsloan commented Mar 14, 2016

I'm not familiar enough with this issue / windows to be much help, sorry! One wild guess is to try temporarily switching the locale to english? That would at least tell us if it's some sort of issue related to locale

@CarstenKoenig

This comment has been minimized.

Show comment
Hide comment
@CarstenKoenig

CarstenKoenig Apr 4, 2016

I just tried again and yes @mgsloan was on the right track.

Thankfully you don't have to reset your complete system.

At least on my german Win8 and Win10 systems - if you change the Language for non-Unicode programs settings in windows (as described here) to Englisch (US)

GhcJs seems to be finally compiling (at least the transformers problem is gone)

CarstenKoenig commented Apr 4, 2016

I just tried again and yes @mgsloan was on the right track.

Thankfully you don't have to reset your complete system.

At least on my german Win8 and Win10 systems - if you change the Language for non-Unicode programs settings in windows (as described here) to Englisch (US)

GhcJs seems to be finally compiling (at least the transformers problem is gone)

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Apr 4, 2016

Contributor

Does anything change if you use GHC 7.10.3 instead of 7.10.2? They fixed some locale issues on Windows in that and Stack disables its workarounds (which were not entirely reliable) when using 7.10.3 or later.

Contributor

borsboom commented Apr 4, 2016

Does anything change if you use GHC 7.10.3 instead of 7.10.2? They fixed some locale issues on Windows in that and Stack disables its workarounds (which were not entirely reliable) when using 7.10.3 or later.

@tlewowski

This comment has been minimized.

Show comment
Hide comment
@tlewowski

tlewowski Sep 24, 2016

Contributor

I have the exactly same problem, also during building GHCJS - transformers not compiling on 64-bit Windows 10 with error commitBuffer: invalid argument (invalid character). Setting LC_ALL etc. didn't help.
I checked stack 1.1.2 and 1.2.0 (no differences - neither works) and GHC 7.10.3 and 7.10.2 (also neither works).
Changing Language for non-Unicode programs to English (US) helped (my usual locale is Polish).
If it's hard to fix and heavily configuration-dependent, it would be great if we at least had a hint in https://docs.haskellstack.org/en/stable/ghcjs/#ghcjs that such problems happen in Windows environments and the workaround is changing locale

Contributor

tlewowski commented Sep 24, 2016

I have the exactly same problem, also during building GHCJS - transformers not compiling on 64-bit Windows 10 with error commitBuffer: invalid argument (invalid character). Setting LC_ALL etc. didn't help.
I checked stack 1.1.2 and 1.2.0 (no differences - neither works) and GHC 7.10.3 and 7.10.2 (also neither works).
Changing Language for non-Unicode programs to English (US) helped (my usual locale is Polish).
If it's hard to fix and heavily configuration-dependent, it would be great if we at least had a hint in https://docs.haskellstack.org/en/stable/ghcjs/#ghcjs that such problems happen in Windows environments and the workaround is changing locale

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Oct 4, 2016

Collaborator

Since there is a documentation fix, closing this for now. If there is something that stack can do better here, please open another issue about it!

Collaborator

mgsloan commented Oct 4, 2016

Since there is a documentation fix, closing this for now. If there is something that stack can do better here, please open another issue about it!

@nh2

This comment has been minimized.

Show comment
Hide comment
@nh2

nh2 Apr 27, 2018

Contributor

I've created #3988 to fix this issue properly so that the workaround linked above should no longer be necessary once done.

Contributor

nh2 commented Apr 27, 2018

I've created #3988 to fix this issue properly so that the workaround linked above should no longer be necessary once done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment