This patch is running for months in Firefox's CI and we didn't observe anything wrong and thanks to it we fixed several timeout issues.
I suppose that in case of hard failures, the partial ccov data are likely useless and everything will be ran again.

My I missed this patch.
I'm fine with it: that stuff is useless.

LGTM

LGTM

It's because you moved fn_list_remove(&writeout_fn_list); in llvm_writeout_files(void)

LGTM

The base patch is not the correct one:
https://reviews.llvm.org/D81650
Oh I think I understand: the patch I made has been uplifted in branch 10 (https://bugs.llvm.org/show_bug.cgi?id=44792#c22) but no the test fix: https://reviews.llvm.org/D79621
So you must uplift patch in D79621 in branch 10 and if the issue is still there then add the try...catch like in D81650.
If it isn't clear enough then you can reach me on irc or discord.

Good catch.

In D54599#2024449, @kawashima-fj wrote:

In D54599#1966949, @marco-c wrote:

I wonder if https://reviews.llvm.org/D76206 didn't fix this too

Sorry, I didn't notice this patch.
Probably D76206 and D79556 fix this too.

Fix nits.

Export symbol for Darwin target

In D75436#1903566, @jfb wrote:

Doing fork will still share an output file, right? Doe we currently end up interleaving content from both forks, or does one of them overwrite the other entirely?
I understand that crashing is undesirable, but wrong data isn't really any better.

Fix a typo

Add more comments to explain why we need to lock around the fork

If exec** fails we need to reset the counters since they've have dumped just before to avoid to count them twice.

OK that helps a bit. I still don't understand though: why do you only need to protect flush and nothing else? You're protecting specific variables from being accesses concurrently only though flush, and not through the other paths that access those variables. Are these variables never accessed concurrently from these other functions?

@jfb, sorry I thought my commit message was clear enough.
So when coverage is enabled a call to __gcov_flush is inserted just before forkcall:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp#L659
So if the parent process is forked in different threads then __gcov_flush is called from different threads.
And so different global variables are accessed asynchronously:
https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/profile/GCDAProfiling.c#L104-L108
Initially we saw crashes in our CI: https://bugzilla.mozilla.org/show_bug.cgi?id=1599436
The above test case leads to multiple errors: double-free, "cannot merge previous GCDA file..."
And in debbuging firefox, I saw output_file == NULL (https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/profile/GCDAProfiling.c#L603) where it mustn't.

@vsk: the test compiler-rt/trunk/test/profile/instrprof-darwin-exports.c was failing probably because of the missing static on gcov_flush_mutex, could you check that it's ok for you ?

Make symbol gcov_flush_mutex private

@ahatanak it's probably a problem with Darwin.cpp where I need to add some exported symbols.
@jfb sorry but it fixes issues with fork:

• we had a lot of crashes in Firefox CI when dumping the GCDAs and so I tried this patch on the CI and no more weird crashes.
• and a minimal test case to reproduce it:

#include <iostream>
#include <thread>
#include <vector>
#include <unistd.h>

Use HEAD~3 with arc diff

Remove unused function

Use SRWLock instead of a CRITICAL_SECTION.

Make a more concise code.

Remove spaces at the beginning of lines

• Update code to take into account what's wrong when fd==-1
• Add a test for GCOV_PREFIX

@RKSimon, thanks, I reverted.

@RKSimon, do you have an example fo failure, because I didn't get anything on mail nor on irc channel ?

Forgot the ellipsis in the release notes.

Update ReleaseNotes

Fix nit.

Fix execvp test.

Handle execve, fix issues with execvp and remove _WIN32.

Looks good to me.

Update doc.