The dsymutil tool left a directory in the tmpdir.

[578559967]

dsymutil creates a temporary directory in tmpdir when it's working, but forgets to remove it upon exiting.
This issue has been present since Clang 14.0.3 or earlier, but not before 14.0.0.
It causes Golang compilation to fail on macOS. See golang/go#59026.

Here is how to reproduce:

$ cat test.c
#include <stdio.h>

int main() {
  printf("hello\n");
}

$ mkdir tmp

$ TMPDIR=$PWD/tmp clang test.c -o test.o -ggdb -c

$ ls tmp

$ TMPDIR=$PWD/tmp clang test.o -o test -ggdb

$ ls tmp

$ TMPDIR=$PWD/tmp dsymutil -f test -o test.k

$ ls tmp
dsymutil-5f58bc

$ clang --version                                                                                                                                                                                                                            
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Until Clang 15.0.7, this issue still exists.

[keith]

Here's a potential fix https://reviews.llvm.org/D147498

[578559967]

Here's a potential fix https://reviews.llvm.org/D147498

So fast! Will this fix be picked to clang 14? And when will mac use this fix?

[keith]

I'm not sure if there will be another release in either the 14 or 15 versions. As far as the apple shipped versions they lag behind quite a bit. I would recommend finding another workaround in the meantime 🫤

[keith]

If you pass --reproducer Off it should avoid it if that works for you

[578559967]

If you pass --reproducer Off it should avoid it if that works for you

It works! Does this option have any side effect?

[keith]

The default is that if dsymutil crashes it will produce a reproducer for filing a bug report. So with this option you will not get that.

[578559967]

The default is that if dsymutil crashes it will produce a reproducer for filing a bug report. So with this option you will not get that.

Got it! Thank you!

[cherrymui]

Thanks for fixing the original issue.
With this change, when DSYMUTIL_REPRODUCER_PATH is set, dsymutil will delete the directory if it doesn't generate a reproducer, even if the directory is not created/owned by dsymutil and is not empty. This is somewhat unexpected. Is this the desired behavior? If so, maybe this should be documented somewhere? (The workaround is easy: always create a new directory for dsymutil.)
Thanks.

[keith]

ha, no not really expected. I don't think the patch should be too bad to fix it. I think we could just change the logic to check the directory for any contents before removing. Want to submit a PR?