-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
ERROR: write: i/o error (EIO) with the new WSL #24310
Comments
I think it might falter every time it hits any non-ASCII character, and I think this might be closer to the underlying cause. When printing documentation, if it crashes, it prints up until the first non-ASCII character and then fails to print the non-ASCII charater. For example, in the above example printing the documentation for The same error (for the first seven items on the stack trace) occurs if you just try to print a string with a non-ASCII character in it. Interestingly, it only happens if it tries to show the string—if you just print the string with julia> print("The next character is ×")
The next character is ×
julia> "The next character is ×"
"The next character is Error showing value of type String:
ERROR: write: i/o error (EIO)
Stacktrace:
[1] try_yieldto(::Base.##296#297{Task}, ::Task) at ./event.jl:189
[2] wait() at ./event.jl:234
[3] uv_write(::Base.TTY, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:811
[4] unsafe_write(::Base.TTY, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:832
[5] unsafe_write(::Base.TTY, ::Base.RefValue{UInt8}, ::Int64) at ./io.jl:293
[6] write(::Base.TTY, ::UInt8) at ./stream.jl:873
[7] write(::IOContext{Base.Terminals.TTYTerminal}, ::Char) at ./io.jl:334
[8] print at ./char.jl:45 [inlined]
[9] escape_string(::IOContext{Base.Terminals.TTYTerminal}, ::String, ::String) at ./strings/io.jl:236
[10] print_quoted at ./strings/io.jl:253 [inlined]
[11] show at ./strings/io.jl:124 [inlined]
[12] show(::IOContext{Base.Terminals.TTYTerminal}, ::MIME{Symbol("text/plain")}, ::String) at ./replutil.jl:147
[13] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::MIME{Symbol("text/plain")}, ::String) at ./REPL.jl:122
[14] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::String) at ./REPL.jl:125
[15] display(::String) at ./multimedia.jl:218
[16] eval(::Module, ::Any) at ./boot.jl:235
[17] print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, ::Bool, ::Void) at ./REPL.jl:144
[18] print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) at ./REPL.jl:129
[19] (::Base.REPL.#do_respond#16{Bool,Base.REPL.##26#36{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState, ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at ./REPL.jl:646 This doesn't actually get at the underlying problem, but hopefully it's a step closer if anyone else looks at this 🙂 Edit: Actually, on second inspection I realized this doesn't really add very much that we didn't already know. But here's an upvote for the issue, anyway. This is on Julia version 0.6.2, on Ubuntu on Windows 10 version 1709. |
It’s informative to see, but since this isn’t a bug with Julia, you should post the same comments on the WSL issue tracker. They’ve been pretty responsive in the past |
Sure, will do. In order to try and provide something useful to the WSL developers, I kept digging. Since I found a workaround, I thought I may as well post it here. Here's a workaround: import Base.write
function write(s::IO, ch::Char)
c = reinterpret(UInt32, ch)
if c < 0x80
return write(s, c%UInt8)
elseif c < 0x800
return write(s, [
(( c >> 6 ) | 0xC0) % UInt8,
(( c & 0x3F) | 0x80) % UInt8,
])
elseif c < 0x10000
return write(s, [
(( c >> 12 ) | 0xE0) % UInt8,
(((c >> 6) & 0x3F) | 0x80) % UInt8,
(( c & 0x3F) | 0x80) % UInt8,
])
elseif c < 0x110000
return write(s, [
(( c >> 18 ) | 0xF0) % UInt8,
(((c >> 12) & 0x3F) | 0x80) % UInt8,
(((c >> 6) & 0x3F) | 0x80) % UInt8,
(( c & 0x3F) | 0x80) % UInt8,
])
else
return write(s, '\ufffd')
end
end That redefines Why this works I don't fully understand. It seems like it works fine when is passed an array of chars, but not when it's passed any single char outside the ASCII range. Maybe the OS expects the entire Unicode character in one go or something (whereas Linux will happily keep the leading byte around in its buffer?). Then when Anyway, I'll report this to the WSL folks some time soon. |
I am using Julia 0.7.0 from WSL (Ubuntu 18.04) with ODBC Driver 17 for SQL Server installed. I got the same
|
I cannot reproduce on WSL and julia 1.0 on Windows 10 build 17758.1 |
With Julia 1.0 and Windows 10 version 1803 (build 17134.285), it's doing better for me than it was on Julia 0.6:
but it still seems to run into the same thing sometimes:
and even with other characters in documentation:
I believe the character that it would be printing next here is I'm not in the Windows Insider Program, so don't have 17758, let me know if you think this is important. (I never did end up reporting this to WSL, I was trying to collect more information at a lower level using a short C program and it ended up in my too-hard basket. Sorry.) Also, the workaround I posted above no longer works in Julia 0.7 or Julia 1.0. I assume changes in io.jl made it no longer sensible. That's not a problem, just mentioning here for the benefit of anyone else who stumbles upon this page looking for a workaround. |
@czlee I can't seem to trigger this bug with any of the stated examples in this issue. This is likely an WSL bug that was fixed. The new windows update (which I think will be released very soon) will fix this issue. |
Cool, that's useful, thanks, I'll check and report after the next Windows GA release. |
The bug is still there. I get the I/o error when trying to display a dataframe using Julia in WSL. |
For what it's worth, all of the examples I posted above now work fine for me, as does the very first Example 1 (DataFrames) in the OP. So I wouldn't want to speak for others, but from my perspective this is now fixed. I'm now on Julia 1.1.1, Windows version 1809 build 17763.678. |
I also use julia 1.1.1 but my windows version is 1803 and build is 17134.885 |
Maybe that's the reason I still see this error |
Every thing works perfectly now after updating windows to version 1903 build 18362.295. |
Perhaps we can close this then? |
Yeah |
Since updating my Windows to the Fall creators update, I get the following error in REPL (using Windows Subsystem for Linux), when printing special objects to the screen.
Julia Version 0.6.0 (2017-06-19 13:05 UTC)
Example 1: DataFrames
Example 2: printing documentation of some functions
The text was updated successfully, but these errors were encountered: