Can one control where clang writes .gcda coverage files? (to avoid crash)

Hi all,

Is there any way to control the location clang writes .gcda coverage files?

I ask because I create nightly builds of my app on a build machine, and when I run the resulting app on a different machine it crashes like so:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000068

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x00007fff8bd021ec flockfile + 15
1 libsystem_c.dylib 0x00007fff8bce3c86 fwrite + 87
2 com.rogue-research.brainsight2 0x000000010285e366 llvm_gcda_start_file + 262
3 com.rogue-research.brainsight2 0x00000001016e9e80 __llvm_gcov_writeout + 16
4 dyld 0x00007fff6ecc015c ImageLoaderMachO::doTermination(ImageLoader::LinkContext const&) + 178
5 dyld 0x00007fff6ecb4591 dyld::runTerminators(void*) + 67
6 libsystem_c.dylib 0x00007fff8bcad7c8 __cxa_finalize + 274
7 libsystem_c.dylib 0x00007fff8bcad652 exit + 18
8 com.apple.AppKit 0x00007fff88f0863e -[NSApplication terminate:] + 1767

Using Intruments, I see the path it's trying to access is a path on the build machine, which does not exist on my machine:

# Caller Function FD Path
1195 llvm_gcda_start_file open_nocancel -1 /Users/builder/rogue_nightly_build/working_copy/brainsight2/trunk/build/Brainsight2.build/Debug/Brainsight.build/Objects-normal/x86_64/RRPCAPointFilterCore.gcda

I consider this an llvm/clang bug; llvm_gcda_start_file() should at the very least handle the error gracefully, write no coverage, and not crash. Do you concur? Shall I file a bug? Any workaround suggestions?

Thanks,

I consider this an llvm/clang bug; llvm_gcda_start_file() should at the very least handle the error gracefully, write no coverage, and not crash. Do you concur?

Agreed.

Shall I file a bug?

Please.

Any workaround suggestions?

No, but it should be reasonably simple to hack it to use "getcwd()" if the path doesn't exist so wouldn't take long to fix up.

-eric

Here you go, thanks:

<http://llvm.org/bugs/show_bug.cgi?id=12358>
<rdar://11111686>

Cheers,

Thanks!

-eric