- User Since
- Jul 20 2018, 8:06 AM (254 w, 2 d)
Jul 5 2022
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.
Feb 17 2021
My I missed this patch.
I'm fine with it: that stuff is useless.
Jul 17 2020
Jun 30 2020
Jun 25 2020
Jun 22 2020
It's because you moved fn_list_remove(&writeout_fn_list); in llvm_writeout_files(void)
Jun 15 2020
The base patch is not the correct one:
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.
Jun 11 2020
Jun 8 2020
Jun 5 2020
Jun 3 2020
May 8 2020
May 7 2020
Apr 24 2020
Apr 20 2020
Export symbol for Darwin target
Apr 16 2020
Mar 5 2020
Mar 2 2020
Feb 24 2020
Feb 21 2020
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.
Feb 5 2020
Jan 6 2020
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?
Dec 12 2019
@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:
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:
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.
Dec 10 2019
@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>
Dec 3 2019
Use HEAD~3 with arc diff
Remove unused function
Use SRWLock instead of a CRITICAL_SECTION.
Dec 2 2019
Nov 28 2018
Make a more concise code.
Remove spaces at the beginning of lines
Nov 17 2018
- Update code to take into account what's wrong when fd==-1
- Add a test for GCOV_PREFIX
Nov 15 2018
Nov 12 2018
@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.
Nov 8 2018
Nov 7 2018
Fix execvp test.
Handle execve, fix issues with execvp and remove _WIN32.
Looks good to me.