mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2b4cdea7f1
rust/src/test/run-pass/out-of-stack.rs

54 lines
1.8 KiB
Rust
Raw Normal View History

std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
Fix inner attribute syntax from `#[foo];` to `#![foo]` From the 0.10 changelog: * The inner attribute syntax has changed from `#[foo];` to `#![foo]`.
2014-04-03 19:55:06 -05:00
#![feature(asm)]
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
Process::new etc should support non-utf8 commands/args The existing APIs for spawning processes took strings for the command and arguments, but the underlying system may not impose utf8 encoding, so this is overly limiting. The assumption we actually want to make is just that the command and arguments are viewable as [u8] slices with no interior NULLs, i.e., as CStrings. The ToCStr trait is a handy bound for types that meet this requirement (such as &str and Path). However, since the commands and arguments are often a mixture of strings and paths, it would be inconvenient to take a slice with a single T: ToCStr bound. So this patch revamps the process creation API to instead use a builder-style interface, called `Command`, allowing arguments to be added one at a time with differing ToCStr implementations for each. The initial cut of the builder API has some drawbacks that can be addressed once issue #13851 (libstd as a facade) is closed. These are detailed as FIXMEs. Closes #11650. [breaking-change]
2014-05-05 16:33:55 -05:00
use std::io::process::Command;
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
use std::os;
use std::str;
// lifted from the test module
test: avoid infinite loop in out-of-stack.rs This fixes #13238. It avoids an infinite loop when compiling the tests with `-g`. Without this change, the debuginfo on `black_box` prevents the method from being inlined, which allows llvm to convert `silent_recurse` into a tail-call. This then loops forever instead of consuming all the stack like it is supposed to. This patch forces inlining `black_box`, which triggers the right error.
2014-04-02 00:07:37 -05:00
// Inlining to avoid llvm turning the recursive functions into tail calls,
// which doesn't consume stack.
#[inline(always)]
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
pub fn black_box<T>(dummy: T) { unsafe { asm!("" : : "r"(&dummy)) } }
fn silent_recurse() {
let buf = [0, ..1000];
black_box(buf);
silent_recurse();
}
fn loud_recurse() {
println!("hello!");
loud_recurse();
test/run-pass/out-of-stack: prevent tco We really do *not* want TCO to kick in. If it does, we'll never blow the stack, and never trigger the condition the test is checking for. To that end, do a meaningless alloc that serves only to get a destructor to run. The addition of nocapture/noalias seems to have let LLVM do more TCO, which hurt this testcase.
2014-03-27 06:54:41 -05:00
black_box(()); // don't optimize this into a tail call. please.
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
}
fn main() {
let args = os::args();
Handle more fallout os::args() no longer auto-borrows to &[~str].
2014-05-04 15:20:47 -05:00
let args = args.as_slice();
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
if args.len() > 1 && args[1].as_slice() == "silent" {
silent_recurse();
} else if args.len() > 1 && args[1].as_slice() == "loud" {
loud_recurse();
} else {
Process::new etc should support non-utf8 commands/args The existing APIs for spawning processes took strings for the command and arguments, but the underlying system may not impose utf8 encoding, so this is overly limiting. The assumption we actually want to make is just that the command and arguments are viewable as [u8] slices with no interior NULLs, i.e., as CStrings. The ToCStr trait is a handy bound for types that meet this requirement (such as &str and Path). However, since the commands and arguments are often a mixture of strings and paths, it would be inconvenient to take a slice with a single T: ToCStr bound. So this patch revamps the process creation API to instead use a builder-style interface, called `Command`, allowing arguments to be added one at a time with differing ToCStr implementations for each. The initial cut of the builder API has some drawbacks that can be addressed once issue #13851 (libstd as a facade) is closed. These are detailed as FIXMEs. Closes #11650. [breaking-change]
2014-05-05 16:33:55 -05:00
let silent = Command::new(args[0].as_slice()).arg("silent").output().unwrap();
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
assert!(!silent.status.success());
De-~[] Reader and Writer There's a little more allocation here and there now since from_utf8_owned can't be used with Vec.
2014-03-26 11:24:16 -05:00
let error = str::from_utf8_lossy(silent.error.as_slice());
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
assert!(error.as_slice().contains("has overflowed its stack"));
Process::new etc should support non-utf8 commands/args The existing APIs for spawning processes took strings for the command and arguments, but the underlying system may not impose utf8 encoding, so this is overly limiting. The assumption we actually want to make is just that the command and arguments are viewable as [u8] slices with no interior NULLs, i.e., as CStrings. The ToCStr trait is a handy bound for types that meet this requirement (such as &str and Path). However, since the commands and arguments are often a mixture of strings and paths, it would be inconvenient to take a slice with a single T: ToCStr bound. So this patch revamps the process creation API to instead use a builder-style interface, called `Command`, allowing arguments to be added one at a time with differing ToCStr implementations for each. The initial cut of the builder API has some drawbacks that can be addressed once issue #13851 (libstd as a facade) is closed. These are detailed as FIXMEs. Closes #11650. [breaking-change]
2014-05-05 16:33:55 -05:00
let loud = Command::new(args[0].as_slice()).arg("loud").output().unwrap();
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
assert!(!loud.status.success());
De-~[] Reader and Writer There's a little more allocation here and there now since from_utf8_owned can't be used with Vec.
2014-03-26 11:24:16 -05:00
let error = str::from_utf8_lossy(silent.error.as_slice());
std: Tweak stack overflow printing for robustness The printing of the error message on stack overflow had two sometimes false assumptions previously. The first is that a local task was always available (it called Local::take) and the second is that it used println! instead of manually writing. The first assumption isn't necessarily true because while stack overflow will likely only be detected in situations that a local task is available, it's not guaranteed to always be in TLS. For example, during a println! call a task may be blocking, causing it to be unavailable. By using Local::try_take(), we can be resilient against these occurrences. The second assumption could lead to odd behavior because the stdout logger can be overwritten to run arbitrary code. Currently this should be possible, but the utility is much diminished because a stack overflow translates to an abort() instead of a failure.
2014-02-19 23:01:50 -06:00
assert!(error.as_slice().contains("has overflowed its stack"));
}
}
Reference in New Issue Copy Permalink