.NET 6 regression on writing to character device

[am11]

Create a console app with following content in Program.cs:

using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;

string path = "/dev/tty";
if (!File.Exists(path))
{
    throw new Exception(path + " is not available in this environment.");
}

var contentBytes = new byte[] { 1, 2, 3 };

using (var cts = new CancellationTokenSource())
{
    Task writingTask = File.WriteAllBytesAsync(path, contentBytes, cts.Token);
    cts.CancelAfter(TimeSpan.FromMilliseconds(500));

    await writingTask;
}

Console.WriteLine("Passed!");

On macOS (x64), run with .NET 5 (5.0.400), it prints Passed!. In .NET 6 (6.0.100-rtm.21479.10) it throws:

Unhandled exception. System.IO.IOException: Device not configured : '/dev/tty'
   at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.ExecuteInternal()
--- End of stack trace from previous location ---
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.GetResult(Int16 token)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.IO.File.<WriteAllBytesAsync>g__Core|72_0(String path, Byte[] bytes, CancellationToken cancellationToken)
   at Program.<Main>$(String[] args) in /Users/adeel/projects/testdevtty/Program.cs:line 21
   at Program.<Main>(String[] args)

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Create a console app with following content in Program.cs:

using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;

string path = "/dev/tty";
if (!File.Exists(path))
{
    throw new Exception(path + " is not available in this environment.");
}

var contentBytes = new byte[] { 1, 2, 3 };

using (var cts = new CancellationTokenSource())
{
    Task writingTask = File.WriteAllBytesAsync(path, contentBytes, cts.Token);
    cts.CancelAfter(TimeSpan.FromMilliseconds(500));

    await writingTask;
}

Console.WriteLine("Passed!");

On macOS (x64), run with .NET 5 (5.0.400), it prints Passed!. In .NET 6 (6.0.100-rtm.21479.10) it throws:

Unhandled exception. System.IO.IOException: Device not configured : '/dev/tty'
   at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.ExecuteInternal()
--- End of stack trace from previous location ---
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.GetResult(Int16 token)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.IO.File.<WriteAllBytesAsync>g__Core|72_0(String path, Byte[] bytes, CancellationToken cancellationToken)
   at Program.<Main>$(String[] args) in /Users/adeel/projects/testdevtty/Program.cs:line 21
   at Program.<Main>(String[] args)

Author:	am11
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[am11]

This is not reproducible on Linux with .NET 6, so macOS (and likely other non-Linux Unices) are affected.

[am11]

Output of sudo dtruss -f ~/.dotnet6/dotnet bin/Release/net6.0/testdevtty.dll 2>&1 | curl -F"sprunge=<-" http://sprunge.us: http://sprunge.us/6QWmAA

^ @tmds, open("/dev/tty" looks normal, nothing is jumping out at me. 😕

[tmds]

Your stacktrace is different:

Unhandled exception. System.IO.IOException: Device not configured : '/dev/tty'
   at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.ExecuteInternal()
--- End of stack trace from previous location ---
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.GetResult(Int16 token)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.IO.File.<WriteAllBytesAsync>g__Core|72_0(String path, Byte[] bytes, CancellationToken cancellationToken)
   at Program.<Main>$(String[] args) in /Users/am11/projects/testdevtty/Program.cs:line 19
   at Program.<Main>(String[] args)

This is interesting:

lseek(0x14, 0x0, 0x1)		 = 0 0

.NET does this to find out whether the file is 'seekable'.

On Linux this fails with ESPIPE. On macOS it succeeds.

That determines whether bytes are written using write or pwrite (introduced in .NET 6):

runtime/src/libraries/System.Private.CoreLib/src/System/IO/RandomAccess.Unix.cs

Lines 93 to 95 in 8e4c996

	int bytesWritten = handle.CanSeek ?
	Interop.Sys.PWrite(handle, bufPtr, GetNumberOfBytesToWrite(buffer.Length), fileOffset) :
	Interop.Sys.Write(handle, bufPtr, GetNumberOfBytesToWrite(buffer.Length));

So on Linux this uses write as before, while on macOS this is now using pwrite which fails.

[tmds]

Your stacktrace is different:

I mean from the one in CI on #58434 which fails on open with the same message. I assume that has to do with how the terminal is setup in CI, and is not a regression.

[am11]

I mean from the one in CI on #58434 which fails on open with the same message

On macOS, I can reproduce that test failure with same stacktrace locally.

tests % pushd /Users/am11/projects/runtime/artifacts/bin/System.IO.FileSystem.Tests/net7.0-Unix-Debug
  /Users/am11/projects/runtime/artifacts/bin/testhost/net7.0-OSX-Debug-x64/dotnet exec --runtimeconfig System.IO.FileSystem.Tests.runtimeconfig.json --depsfile System.IO.FileSystem.Tests.deps.json xunit.console.dll System.IO.FileSystem.Tests.dll -xml testResults.xml -nologo -method System.IO.Tests.File_ReadWriteAllBytes.ReadAllBytes_NonSeekableFileStream_InUnix -notrait category=OuterLoop -notrait category=failing
~/projects/runtime/artifacts/bin/System.IO.FileSystem.Tests/net7.0-Unix-Debug ~/projects/runtime/src/libraries/System.IO.FileSystem/tests
  Discovering: System.IO.FileSystem.Tests (method display = ClassAndMethod, method display options = None)
  Discovered:  System.IO.FileSystem.Tests (found 1 of 3860 test case)
  Starting:    System.IO.FileSystem.Tests (parallel test collections = on, max threads = 12)
    System.IO.Tests.File_ReadWriteAllBytes.ReadAllBytes_NonSeekableFileStream_InUnix [FAIL]
      System.IO.IOException : Device not configured : '/dev/tty'
      Stack Trace:
        /Users/am11/projects/runtime/src/libraries/System.Private.CoreLib/src/System/IO/Strategies/FileStreamHelpers.Unix.cs(24,0): at System.IO.Strategies.FileStreamHelpers.CheckFileCall(Int64 result, String path, Boolean ignoreNotSupported)
        /Users/am11/projects/runtime/src/libraries/System.Private.CoreLib/src/System/IO/RandomAccess.Unix.cs(97,0): at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)
        /Users/am11/projects/runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.ThreadPoolValueTaskSource.cs(102,0): at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.ExecuteInternal()
        --- End of stack trace from previous location ---
        /Users/am11/projects/runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.ThreadPoolValueTaskSource.cs(71,0): at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.GetResult(Int16 token)
        /Users/am11/projects/runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.ThreadPoolValueTaskSource.cs(65,0): at Microsoft.Win32.SafeHandles.SafeFileHandle.ThreadPoolValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
        /Users/am11/projects/runtime/src/libraries/System.Private.CoreLib/src/System/IO/File.cs(848,0): at System.IO.File.<WriteAllBytesAsync>g__Core|72_0(String path, Byte[] bytes, CancellationToken cancellationToken)
        /Users/am11/projects/runtime/src/libraries/System.IO.FileSystem/tests/File/ReadWriteAllBytes.cs(228,0): at System.IO.Tests.File_ReadWriteAllBytes.ReadAllBytes_NonSeekableFileStream_InUnix()
        --- End of stack trace from previous location ---
  Finished:    System.IO.FileSystem.Tests
=== TEST EXECUTION SUMMARY ===
   System.IO.FileSystem.Tests  Total: 1, Errors: 0, Failed: 1, Skipped: 0, Time: 3.470s

I am still building PR branch on Ubuntu, but I have a theory the test is failing on Linux with ENXIO because output and error streams (not input stream) are redirected, we would probably just need to skip the test in redirect case.

[tmds]

The root cause is that CanSeek does not indicate support for pwrite/pread.

I see two options:

• Let Stream use write/read always. Then using Stream always works. Using RandomAccess may not work for files that don't support random access (like /dev/tty).
  This has a behavioral impact on Stream which does now do its own position tracking and uses that offset for reading/writing.
• Make RandomAccess fall back from pread/pwrite to read/write after observing specific errors like ESPIPE and ENXIO.

@stephentoub @am11 @jozkee @carlossanlop @adamsitnik do you prefer one of these options? or see other options?

[jozkee]

Why lseek succeds in macOS? Even the doc page says that it should fail with ESPIPE for a FIFO.
Could another approach be: fix CanSeek in macOS so it can behave as Linux?

[jozkee]

Let Stream use write/read always. Then using Stream always works. Using RandomAccess may not work for files that don't support random access (like /dev/tty).
This has a behavioral impact on Stream which does now do its own position tracking and uses that offset for reading/writing.

Could there be any perf. regressions in doing this? I assume perf. was the main reason why we changed to pread/pwrite.