File::GetStdioHandleType() should distinguish between an error and an unknown type

[zanderso]

File::GetStdioHandleType() is called when setting up the streams for the dart:io top-levels stdout, stderr, and stdin. It does not distinguish between an error (e.g. fstat() returning -1) and an unknown stat st_mode field. If there is an error, the resulting FileSystemException could contain the errno, strerror, etc. info.

See:

sdk/runtime/bin/file_macos.cc

Line 584 in 2bde0e1

File::StdioHandleType File::GetStdioHandleType(int fd) {

It's probably a separate API usability issue that touching a top-level getter can throw an exception, but that might also warrant some attention.

@a-siva @zichangg

[sortie]

How can fstat() fail on stdin, stdout, or stderr? The only errors that could happen are EBADF (if somehow dart is run without fd 0, 1, or 2, which one cannot expect to work for normal programs) and EFAULT (bad pointer, shouldn't be possible).

[zanderso]

Three things:

1. We're seeing flutter_tool crashes in the wild on touching the stdin top-level getter. With so many users, we can't really count on OS calls failing only in the documented/expected way. Either fstat() is failing because the user's machine or invocation of the flutter_tool is broken, or GetStdioHandleType() needs to handle more st_mode cases. (Or fstat() is just returning something totally bogus in the buffer.)
2. An embedder can manually override the fds for stdout, stderr, and stdio. See: https://github.com/dart-lang/sdk/blob/master/sdk/lib/io/stdio.dart#L400.
3. Programs can certainly run even if the embedder has closed fds 0, 1, and 2, or if the OS never wired them up when starting the process.

On thinking about this more, kOther should probably fall back on treating stdout and stderr as pipes, and the getter should only fail if the fstat() returns -1. If pipe was a bad guess for kOther, then we'll get an exception only if we try to write, which is a bit more intuitive API-wise, I think.