search

xd009642 / tarpaulin

A code coverage tool for Rust projects
https://crates.io/crates/cargo-tarpaulin
Apache License 2.0
2.5k stars 180 forks source link

Poor interactions with SIGCHLD-using projects #778

Open mathstuf opened 3 years ago

mathstuf commented 3 years ago

Describe the bug I have a project that uses wait-timeout to check the timeout of some commands that are executed. By some printf debugging (unless there's some way to run tarpaulin under gdb), it seems that the SIGCHLD handler in wait-timeout is not being executed at all. Tarpaulin should chain off to any already installed signal handlers (if at all possible). Alternatively, it could be that something goes wrong when installing wait-timeout's signal handler?

Alternatively, maybe some way to disable interposition on SIGCHLD handler could be done?

To Reproduce A simple example wasn't doing it, but the crate in question is here.

Expected behavior Already installed SIGCHLD handlers should work.

xd009642 commented 3 years ago

Have you tried --forward as a CLI arg, it forwards unexpected signals to the test process. I was considering making it default but I didn't know if it would break certain things

mathstuf commented 3 years ago

Ah, I had missed that flag. Trying now, thanks.

mathstuf commented 3 years ago

Hrm. Alas, that doesn't seem to resolve it for me. The odd thing is that the underlying crate which actually does the work is fine. It's when it's all driven from other threads and such using Tokio to manage communications via a Unix socket and other event sources that things end up going south.

jrray commented 2 years ago

I am facing a similar problem with a project that uses tokio::process::Command, which currently relies on SIGCHLD to get woken up. The subprocess exits but the parent process (my test) never stops waiting for the child process. Using --forward doesn't help.

There is some talk of removing the use of SIGCHLD here.

xd009642 commented 1 year ago

I'd generally say now --engine llvm is potentially a solution the only issue is the llvm coverage instrumentation doesn't really handle threads or spawned processes well so results can differ from run-to-run. A lot has gone into tarpaulin since last comment so just wondering if things have changed for anyone?