Skip to content
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

Silently dropped errors in std #28

Closed
uazu opened this issue Mar 25, 2018 · 7 comments
Closed

Silently dropped errors in std #28

uazu opened this issue Mar 25, 2018 · 7 comments

Comments

@uazu
Copy link

uazu commented Mar 25, 2018

FileDesc::drop silently drops the error if close() fails. How could we get this error out to the user code? Is there any other code that silently drops errors?

One model might be for std to keep a (short, fixed) queue of unreported errors globally. FileDesc::drop could push any error onto this queue. There could be a function for user code to call to check whether there are any pending errors to deal with, and return the error. (This maybe has some overlap with dealing with SIGINT and SIGTERM, when those are being caught.)

Any other ideas?

@BurntSushi
Copy link

It would help to motivate this. What problem are people trying to solve by examining the error returned by close? Flipping that question around is also interesting, namely, what do people hope to infer by a close call executing successfully?

Is it possible that those problems can be solved with appropriate use of fsync when desired?

Note that reading the full man page, man 2 close, is informative on this topic. I believe this particular topic has been discussed quite a bit before a few years ago, but I don't know where it took place.

@uazu
Copy link
Author

uazu commented Mar 25, 2018

For me, it's loss of information. Maybe the close fails and then somewhere down the line something else fails as a consequence. Then you have to debug all the way back to this failing close. If you had the error reported at the close itself, it saves all that effort.

Also, close is not just for files, but also devices, and devices can be weird. I want to know about anything that goes wrong with a device, as soon as it happens. If this is part of a multi-layered long-lived system, then an occasional close failure could translate to some strange intermittent problem at higher layers. Being strict about logging anything weird really saves time IMHO.

@BurntSushi
Copy link

BurntSushi commented Mar 25, 2018

Concrete examples would be helpful here. As far as I can tell, it is easy to implement this oneself using libc::close, right? I mean, I don't think this is a common footgun for folks writing CLI tools? At least, I haven't heard of it being one but I could be wrong!

@uazu
Copy link
Author

uazu commented Mar 25, 2018

So you're saying that the suggested solution is to bypass 'std' if you want error information from close? Perhaps that should be documented.

I have to work with 3rd party serial drivers, some of which can at times be very buggy. However I can't think of an example right now where the error showed up on close. (Although when things go wrong, any syscall including close might lock up the process totally.) With filesystems, you're counting on nothing weird going on. Searching around, AFS could give errors on close, and I suppose any FUSE filesystem might do the same. I guess perhaps that doesn't seem mainstream enough to worry about.

It seems strange in Rust to be told (effectively) to be less paranoid and just relax and ignore the errors, when Rust is all about being strict and not letting any failure be ignored. I always check close() return in other languages. But maybe that's not the Rust way. So if no-one else is concerned about this, I'm willing to drop it.

@BurntSushi
Copy link

BurntSushi commented Mar 25, 2018

@uazu I'm asking if this is actually, in practice, a common footgun when developing CLI applications for Rust. This is the CLI working group, so if it isn't, it might be out of scope for this particular WG.

It seems strange in Rust to be told (effectively) to be less paranoid and just relax and ignore the errors, when Rust is all about being strict and not letting any failure be ignored.

General principles can almost always be used to arrive at any kind of conclusion you want. It is critically important that we focus on real concrete examples, because that's what matters at the end of the day. Certainly, I am not making any general claim that involves being "less paranoid" or "relaxed" about errors.

I wish I knew where the discussion on this topic took place was. It was quite in depth.

@BurntSushi
Copy link

BurntSushi commented Mar 25, 2018

@uazu
Copy link
Author

uazu commented Mar 26, 2018

Okay, I agree this has all been discussed much more comprehensively elsewhere. Thanks for the links. Whilst it affects any CLI tool that works with files or devices, it's not specific to CLI tools. It's not possible to say that CLI tools are simpler so it won't matter, because they may be running as part of a much bigger system. The right thing to do on close failure is probably to report an error to stderr and exit(1), which should end up in some log somewhere if it's being run as part of a larger task.

However, this came up in the original thread of #12 because of the general need for queuing not-directly-reportable errors from other sources, which might include ^C handling and also maybe println!, which are more specifically related to CLIs. I split it out here because it seemed to be confusing the original thread of conversation, but really it is related to those other two.

I will close this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants