Tarpaulin v0.18 seems to randomly segfault in tests that fork

[cptpcrd]

Describe the bug

I have tests that need to fork() in order to test certain things in a child process (and yes, I try to be careful about considering async-signal-safety). I recently noticed some of them segfaulting, and was puzzled by the behavior I got when I tried changing them slightly.

To Reproduce

I think this best illustrates the bizarre nature of this bug (if needed, I can come up with further examples):

#[test]
pub fn test1()  {
    fn child<F: FnOnce()>(f: F) {
        match unsafe { libc::fork() } {
           0 => {
               f();
               unsafe {
                   libc::_exit(0);
               }
           },
           -1 => println!("Fork failed"),
           pid => unsafe {
               libc::waitpid(pid, core::ptr::null_mut(), 0);
           },
        }
    }

    child(|| ());
}

#[test]
pub fn test2()  {
    match unsafe { libc::fork() } {
       0 => unsafe { libc::_exit(0); },
       -1 => println!("Fork failed"),
       pid => unsafe {
           libc::waitpid(pid, core::ptr::null_mut(), 0);
       },
    }
}

#[test]
pub fn test3()  {
    match unsafe { libc::fork() } {
       0 => {
           unsafe {
               libc::_exit(0);
           }
       },
       -1 => println!("Fork failed"),
       pid => unsafe {
           libc::waitpid(pid, core::ptr::null_mut(), 0);
       },
    }
}

cargo tarpaulin -- test1 and cargo tarpaulin -- test3 segfault, but cargo tarpaulin -- test2 runs fine -- even though test2 and test3 seem to compile to the same assembly!

I'm running this on x86_64 Arch (kernel 5.12.15) with rustc 1.53.0, but I've also been able to reproduce this on Ubuntu 20.04 with rustc 1.52.1, so I don't think it's kernel/rustc-specific.

Expected behavior

Tarpaulin should not segfault when run on any of the above tests.

[xd009642]

I realise I haven't commented on this yet, but I have reproduced and started looking at fixing it but there's some general life stuff which is making development a bit slower for me. I'll hopefully get a chance to get back to it this week or next

[xd009642]

I've managed to solve this on my local reproduction and added a test for it. It'll be in develop once https://github.com/xd009642/tarpaulin/pull/859 merges and when it's done I aim to see how many other issues I can get done this weekend and cut a new release before the start of next week