Skip to content

[sanitizer_common][test] Remove second SanitizerCommon.ReportFile tem… #126509

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

rorth
Copy link
Collaborator

@rorth rorth commented Feb 10, 2025

…p file

The SanitizerCommon.ReportFile test leaves a temp file behind on every run. While this is not a problem for manual builds, on buildbots those files accumulate over time, interfering with other bots on the same system.

The files in question are named like
sanitizer_common.reportfile.tmp.XXXXXX.<pid>. The issue can be seen in Solaris truss output:

22633:	fstatat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0xFEFFBAD0, AT_SYMLINK_NOFOLLOW) Err#2 ENOENT
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja.22633", O_WRONLY|O_CREAT|O_TRUNC, 0660) = 4
22633:	unlinkat(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0) = 0

The first temp file, created by temp_file_name, is removed at the end of the test, the second one, created in ReportFile::GetReportPath using OpenFile, is not.

This patch fixes this, simply removing the file.

Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.

…p file

The SanitizerCommon.ReportFile leaves a temp file behind on every run.
While this is not a problem for manual builds, on buildbots those file
accumulate over time, interfering with other bots on the same system.

The files in question are named like
`sanitizer_common.reportfile.tmp.XXXXXX.<pid>`.  The issue can be seen in
Solaris `truss` output:
```
22633:	fstatat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0xFEFFBAD0, AT_SYMLINK_NOFOLLOW) Err#2 ENOENT
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja.22633", O_WRONLY|O_CREAT|O_TRUNC, 0660) = 4
22633:	unlinkat(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0) = 0
```
The first temp file, created by `temp_file_name`, is removed at the end of
the test, the second one, created in `ReportFile::GetReportPath` using
`OpenFile`, is not.

This patch fixes this, simply removing the file.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
@llvmbot
Copy link
Member

llvmbot commented Feb 10, 2025

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Rainer Orth (rorth)

Changes

…p file

The SanitizerCommon.ReportFile test leaves a temp file behind on every run. While this is not a problem for manual builds, on buildbots those files accumulate over time, interfering with other bots on the same system.

The files in question are named like
sanitizer_common.reportfile.tmp.XXXXXX.&lt;pid&gt;. The issue can be seen in Solaris truss output:

22633:	fstatat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0xFEFFBAD0, AT_SYMLINK_NOFOLLOW) Err#<!-- -->2 ENOENT
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja.22633", O_WRONLY|O_CREAT|O_TRUNC, 0660) = 4
22633:	unlinkat(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0) = 0

The first temp file, created by temp_file_name, is removed at the end of the test, the second one, created in ReportFile::GetReportPath using OpenFile, is not.

This patch fixes this, simply removing the file.

Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.


Full diff: https://github.com/llvm/llvm-project/pull/126509.diff

1 Files Affected:

  • (modified) compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp (+1)
diff --git a/compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp b/compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp
index 272520fa51f01e2..1bec83be4c80bd6 100644
--- a/compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp
+++ b/compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp
@@ -352,6 +352,7 @@ TEST(SanitizerCommon, ReportFile) {
   // This will close tmpfile.
   report_file.SetReportPath("stderr");
   Unlink(tmpfile);
+  Unlink(path);
 }
 
 TEST(SanitizerCommon, FileExists) {

@rorth rorth merged commit a058741 into llvm:main Feb 11, 2025
10 checks passed
Icohedron pushed a commit to Icohedron/llvm-project that referenced this pull request Feb 11, 2025
llvm#126509)

…p file

The `SanitizerCommon.ReportFile` test leaves a temp file behind on every
run. While this is not a problem for manual builds, on buildbots those
files accumulate over time, interfering with other bots on the same
system.

The files in question are named like
`sanitizer_common.reportfile.tmp.XXXXXX.<pid>`. The issue can be seen in
Solaris `truss` output:
```
22633:	fstatat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0xFEFFBAD0, AT_SYMLINK_NOFOLLOW) Err#2 ENOENT
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja.22633", O_WRONLY|O_CREAT|O_TRUNC, 0660) = 4
22633:	unlinkat(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0) = 0
```
The first temp file, created by `temp_file_name`, is removed at the end
of the test, the second one, created in `ReportFile::GetReportPath`
using `OpenFile`, is not.

This patch fixes this, simply removing the file.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
joaosaffran pushed a commit to joaosaffran/llvm-project that referenced this pull request Feb 14, 2025
llvm#126509)

…p file

The `SanitizerCommon.ReportFile` test leaves a temp file behind on every
run. While this is not a problem for manual builds, on buildbots those
files accumulate over time, interfering with other bots on the same
system.

The files in question are named like
`sanitizer_common.reportfile.tmp.XXXXXX.<pid>`. The issue can be seen in
Solaris `truss` output:
```
22633:	fstatat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0xFEFFBAD0, AT_SYMLINK_NOFOLLOW) Err#2 ENOENT
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja.22633", O_WRONLY|O_CREAT|O_TRUNC, 0660) = 4
22633:	unlinkat(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0) = 0
```
The first temp file, created by `temp_file_name`, is removed at the end
of the test, the second one, created in `ReportFile::GetReportPath`
using `OpenFile`, is not.

This patch fixes this, simply removing the file.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
sivan-shani pushed a commit to sivan-shani/llvm-project that referenced this pull request Feb 24, 2025
llvm#126509)

…p file

The `SanitizerCommon.ReportFile` test leaves a temp file behind on every
run. While this is not a problem for manual builds, on buildbots those
files accumulate over time, interfering with other bots on the same
system.

The files in question are named like
`sanitizer_common.reportfile.tmp.XXXXXX.<pid>`. The issue can be seen in
Solaris `truss` output:
```
22633:	fstatat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0xFEFFBAD0, AT_SYMLINK_NOFOLLOW) Err#2 ENOENT
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
22633:	openat64(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja.22633", O_WRONLY|O_CREAT|O_TRUNC, 0660) = 4
22633:	unlinkat(AT_FDCWD, "/tmp/sanitizer_common.reportfile.tmp.rzVEja", 0) = 0
```
The first temp file, created by `temp_file_name`, is removed at the end
of the test, the second one, created in `ReportFile::GetReportPath`
using `OpenFile`, is not.

This patch fixes this, simply removing the file.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants