-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
logging macros and writeln!() crash if stderr is redirected to /dev/null #10626
Comments
I see the same behavior if instead I explicitly set the descriptors to
|
What is the expected behavior? This appears to all be working as-intended to me. You have instructed the child to print something, but you have not provided a method of it to print anything, and it's aborting as a result. It could be a bug that it's aborting incorrectly, but that seems separate from this issue. |
I expect the child to exit normally. I discovered that I actually don't need the parent process in order to see the unexpected behavior.
Here are some of gdb stack traces I see when the crash occurs:
Also, the following program shows the same behavior.
|
For comparison, the following program behaves as I think the other versions of "child.rs" ought to.
However, it reverts back to the bad behavior if I change it to:
|
This is both useful for performance (otherwise logging is unbuffered), but also useful for correctness. Because when a task is destroyed we can't block the task waiting for the logger to close, loggers are opened with a 'CloseAsynchronously' specification. This causes libuv do defer the call to close() until the next turn of the event loop. If you spin in a tight loop around printing, you never yield control back to the libuv event loop, meaning that you simply enqueue a large number of close requests but nothing is actually closed. This queue ends up never getting closed, meaning that if you keep trying to create handles one will eventually fail, which the runtime will attempt to print the failure, causing mass destruction. Caching will provide better performance as well as prevent creation of too many handles. Closes #10626
Clippy Book Chapter Updates Reborn: Trait Checking This PR adds a new chapter to the book: "Trait Checking". No major changes from the source (just some typos, re-phrasing, the usual). ## Notes - Does not require any other PR to be merged. - To talk about the whole project, please use the tracking issue for the project rust-lang#10597 (It also contains a timeline, discussions and more information) changelog: Add a new "Trait Checking" chapter to the book
The following occurs for me on Mac OSX 10.9.
When I run
./parent
, I expect the output to be "exit code: 0". Instead, I see an error signal, and not always the same one:The text was updated successfully, but these errors were encountered: