Skip to content
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

Object files for C++ input files are placed right next to source files #1367

Closed
bbannier opened this issue Jan 31, 2023 · 1 comment · Fixed by #1368
Closed

Object files for C++ input files are placed right next to source files #1367

bbannier opened this issue Jan 31, 2023 · 1 comment · Fixed by #1368
Assignees
Labels
Bug Something isn't working JIT

Comments

@bbannier
Copy link
Member

If one adds a C++ file to a JIT invocation, the temporary object file is placed right next to the source file (which likely resides in some version-controlled directory, not even a build dir). The name of the object file is not unique. If multiple JIT jobs use the C++ file this will lead to races on the output file where different jobs might remove each others temporary file.

// Initially we expect four files (stdout, stderr, log, input).
// @TEST-EXEC: test $(find . -type f | wc -l) -eq 4
//
// JIT the C++ file and keep the output file. It should end in the temp dir.
// @TEST-EXEC: spicyc -jT %INPUT
//
// We still expect four files (stdout, stderr, log, input).
// @TEST-EXEC: test $(find . -type f | wc -l) -eq 4

void f() {}
@bbannier bbannier added Bug Something isn't working JIT labels Jan 31, 2023
@bbannier bbannier self-assigned this Jan 31, 2023
bbannier added a commit that referenced this issue Jan 31, 2023
We previously would derive the name of the object file to generate for a
given C++ input file directly from the input filename by just replacing
the extension. This caused us to generate object files directly next to
C++ files added explicitly to the JIT job. Multiple jobs using the same
C++ input file could then race on the object file.

With this patch we make sure that object files are always generated with
taking the JIT has into account. We also fix the location of object
files to always be in a system temp directory.

Closes #1367.
bbannier added a commit that referenced this issue Jan 31, 2023
We previously would derive the name of the object file to generate for a
given C++ input file directly from the input filename by just replacing
the extension. This caused us to generate object files directly next to
C++ files added explicitly to the JIT job. Multiple jobs using the same
C++ input file could then race on the object file.

With this patch we make sure that object files are always generated with
taking the JIT has into account. We also fix the location of object
files to always be in a system temp directory.

Closes #1367.

(cherry picked from commit 580443e)
bbannier added a commit that referenced this issue Jan 31, 2023
We previously would derive the name of the object file to generate for a
given C++ input file directly from the input filename by just replacing
the extension. This caused us to generate object files directly next to
C++ files added explicitly to the JIT job. Multiple jobs using the same
C++ input file could then race on the object file.

With this patch we make sure that object files are always generated with
taking the JIT has into account. We also fix the location of object
files to always be in a system temp directory.

Closes #1367.

(cherry picked from commit 580443e)
@bbannier
Copy link
Member Author

Also backported to release/1.5 and release/1.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working JIT
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant