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

cargo test doesn't capture print from threads #42474

Closed
kpcyrd opened this issue Jun 6, 2017 · 9 comments · Fixed by #78227
Closed

cargo test doesn't capture print from threads #42474

kpcyrd opened this issue Jun 6, 2017 · 9 comments · Fixed by #78227
Labels
A-libtest Area: `#[test]` / the `test` library C-feature-accepted Category: A feature request that has been accepted pending implementation. P-low Low priority T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@kpcyrd
Copy link

kpcyrd commented Jun 6, 2017

I've filed this bug in rust-lang/cargo but I'm afraid rust-lang/rust is the correct repo for this.

I ran the tests for one of my crates that uses threads in its example code. I've noticed it printed some lines to stdout, even though --nocapture wasn't set, but not all of them. It appears that text printed from new threads are not correctly captured, I think this is not intended.

Reproduce

#[cfg(test)]
mod tests {
    use std::thread;
    use std::time::Duration;

    #[test]
    fn it_works() {
        thread::spawn(move || {
            println!("request: {:?}", 123);
        });

        thread::sleep(Duration::from_secs(1));
        println!("response: {:?}", 456);
    }

Output

running 2 tests
request: 123
test tests::it_works ... ok
[...]

Meta

rustc --version --verbose:

rustc 1.17.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.17.0
LLVM version: 4.0
@Mark-Simulacrum Mark-Simulacrum added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 6, 2017
@retep998
Copy link
Member

retep998 commented Jun 6, 2017

set_print (which is what tests use to capture stdout) modifies a thread local, so it only captures output on that exact thread. If you spawn a new thread, it starts with fresh thread locals and so stdout isn't captured.

@Mark-Simulacrum Mark-Simulacrum added A-libtest Area: `#[test]` / the `test` library C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 27, 2017
@mathstuf
Copy link
Contributor

In my tests, I use log in my code and the the tests set up a simple println! logger when they run. Is there some way to have the log implementation send the output to the right place?

@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 19, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 19, 2017

I would be interested in seeing a fix for this in a PR.

@mathstuf
Copy link
Contributor

It'd be nice if there were some way to ask the current test "what print sink are you using?" so that it can pass them down to any spawned threads. That would at least work for "manual" threads. It wouldn't work for things like Rayon (AFAIK).

@azriel91
Copy link
Contributor

CAD97 added a commit to CAD97/rust that referenced this issue May 5, 2018
@Mark-Simulacrum Mark-Simulacrum added the P-low Low priority label Sep 1, 2019
rrbutani added a commit to ut-utp/core that referenced this issue Mar 29, 2020
…cessfully

The contents of this commit have a good account of the things that were tried.
The short version is that there isn't much we can do until rust-lang/rust#42474 is fixed (and ← seems to be blocked on custom test frameworks).
tmandry added a commit to tmandry/rust that referenced this issue Aug 18, 2020
tmandry added a commit to tmandry/rust that referenced this issue Aug 18, 2020
Capture output from threads spawned in tests

Fixes rust-lang#42474.

r? @dtolnay since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.
tmandry added a commit to tmandry/rust that referenced this issue Aug 18, 2020
Capture output from threads spawned in tests

Fixes rust-lang#42474.

r? @dtolnay since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 25, 2020
…, r=m-ou-se

Capture output from threads spawned in tests

This is revival of rust-lang#75172.

Original text:
> Fixes rust-lang#42474.
>
> r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.

---

Closes rust-lang#75172.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 25, 2020
…, r=m-ou-se

Capture output from threads spawned in tests

This is revival of rust-lang#75172.

Original text:
> Fixes rust-lang#42474.
>
> r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.

---

Closes rust-lang#75172.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 26, 2020
…, r=m-ou-se

Capture output from threads spawned in tests

This is revival of rust-lang#75172.

Original text:
> Fixes rust-lang#42474.
>
> r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.

---

Closes rust-lang#75172.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 26, 2020
…, r=m-ou-se

Capture output from threads spawned in tests

This is revival of rust-lang#75172.

Original text:
> Fixes rust-lang#42474.
>
> r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.

---

Closes rust-lang#75172.
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 27, 2020
…r=m-ou-se

Capture output from threads spawned in tests

This is revival of rust-lang#75172.

Original text:
> Fixes rust-lang#42474.
>
> r? `@​dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.

---

Closes rust-lang#75172.
@bors bors closed this as completed in d0d0e78 Oct 27, 2020
@golergka
Copy link

golergka commented Sep 5, 2021

Although this issue is closed, some issues that were closed before as duplicates as this are still not solved: std::io::stdout().write_line("example"); still is not captured by tests.

@akhouderchah
Copy link

+1. Looks like the solution (d0d0e78, 11ce918) was for print_to (and consequently _print & macros) to redirect to OUTPUT_CAPTURE if set.

IIUC, this leaves any direct usage of stdout() uncaptured.

The title doesn't cover this specific issue, but this essentially became a meta-bug by closing all the other output capture issues as dupes. Seems like either this bug or something like #12309 should be reopened.

@jsoneaday
Copy link

jsoneaday commented Jan 29, 2023

+1. Looks like the solution (d0d0e78, 11ce918) was for print_to (and consequently _print & macros) to redirect to OUTPUT_CAPTURE if set.

IIUC, this leaves any direct usage of stdout() uncaptured.

The title doesn't cover this specific issue, but this essentially became a meta-bug by closing all the other output capture issues as dupes. Seems like either this bug or something like #12309 should be reopened.

12309 is closed and points to this issue and this issue is claimed as a duplicate. Is this ever going to get fixed?

@akhouderchah
Copy link

12309 is closed and points to this issue and this issue is claimed as a duplicate. Is this ever going to get fixed?

#90785 is open, but I wouldn't hold my breath unless someone's throwing out PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-libtest Area: `#[test]` / the `test` library C-feature-accepted Category: A feature request that has been accepted pending implementation. P-low Low priority T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
9 participants