We are currently building with the sandbox disabled, as the sandbox prevents the instrumented build to save gcda files with the coverage counters when the process exits. The files are stored in the path defined in the 'GCOV_PREFIX' env variable. How can we make the sandbox allow writing gcda files?

I'm extremely wary of adding lots of special cases for things like this. Is there a reason IPC can't be used to send the values to the parent process for writing?

(In reply to Alex Gaynor [:Alex_Gaynor] from comment #1) > I'm extremely wary of adding lots of special cases for things like this. > > Is there a reason IPC can't be used to send the values to the parent process > for writing? The build is instrumented by the compiler, which injects code to write the gcda files either in a static destructor (GCC) or using atexit (LLVM), so we have no control in how these files are written. Can we add a special case behind the MOZ_CODE_COVERAGE definition? This way we don't risk the special case "spreading" to normal builds.

(In reply to Alex Gaynor [:Alex_Gaynor] from comment #1) > I'm extremely wary of adding lots of special cases for things like this. > > Is there a reason IPC can't be used to send the values to the parent process > for writing? It's definitely *possible* to replace the coverage runtime, to use gcov in environments that don't have stdio (e.g., an OS kernel), but I'm not volunteering to do it and I'd personally prefer just allowing $GCOV_PREFIX in coverage builds. Incidentally, ASan has a code coverage feature with a facility for the application to notify it before it's sandboxed so it can pre-open the output file(s), and we have code to call it, but currently we disable sandboxing on ASan builds due to conflicts with LSan, and there wasn't a way to use sanitizer coverage with gcov-based analysis tools the last time I checked.

We're actually disabling it in Windows and Mac coverage builds too now, but I'm not sure that's needed.