-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Open
Labels
A-reproducibilityArea: Reproducible / deterministic buildsArea: Reproducible / deterministic buildsC-bugCategory: This is a bug.Category: This is a bug.I-prioritizeIssue: Indicates that prioritization has been requested for this issue.Issue: Indicates that prioritization has been requested for this issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-untriagedUntriaged performance or correctness regression.Untriaged performance or correctness regression.
Description
PR 141769 looks like it introduced non-determinism in the generation of dylibs -- it is looking like the tmpdir
is being introduced into the linker map file -- perhaps when creating the .rustc
section here:
pub fn create_compressed_metadata_file( |
We are seeing it in determinism-validation builds in Fuchsia.
Note: the original description claimed that the .so
files had also changed, hence some of the discussion below.
Although the .so
files are identical, we are seeing .so.map
files differing, with distinct tmp paths, e.g.:
f91ef f91ef 431 1 .../rust/linux-x64/lib/rustlib/x86_64-unknown-fuchsia/lib/libcompiler_builtins-84c11efc675a4b65.rlib(compiler_builtins-84c11efc675a4b65.compiler_builtins.ac0a882909fb5ff0-cgu.018.rcgu.o):(.debug_line)
f9620 f9620 30d 1 obj/zircon/system/ulib/sync/libsync.a(libsync.mutex.c.o):(.debug_line)
0 0 1cf28a 1 .rustc
- 0 0 1cf28a 1 /tmp/rustcli35e4/rmeta.o:(.rustc)
+ 0 0 1cf28a 1 /tmp/rustcvBrdn3/rmeta.o:(.rustc)
0 0 1cf28a 1 rust_metadata_vfs_3772e3b421ca7a16
0 0 187 1 .debug_loclists
0 0 22b 1 obj/zircon/system/ulib/sync/libsync.a
Suggested label: A-reproducibility
Metadata
Metadata
Assignees
Labels
A-reproducibilityArea: Reproducible / deterministic buildsArea: Reproducible / deterministic buildsC-bugCategory: This is a bug.Category: This is a bug.I-prioritizeIssue: Indicates that prioritization has been requested for this issue.Issue: Indicates that prioritization has been requested for this issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-untriagedUntriaged performance or correctness regression.Untriaged performance or correctness regression.
Activity
workingjubilee commentedon Jun 24, 2025
cc @bjorn3 looks like we need to add a few
.sort()
ssteven807 commentedon Jun 24, 2025
I added a bit more information to the bug -- it's not just the ordering (that
sort()
s would fix) -- there are actual tmp paths being embedded in the.so.map
filesfangism commentedon Jun 24, 2025
https://g-issues.fuchsia.dev/issues/427157992#comment2 shows that it is the basename of the temporary object file that is different across runs and leaking into the built outputs, akin to
mktemp -t rustcXXXXXX.o
.workingjubilee commentedon Jun 25, 2025
@fangism I can't see your bug tracker. It's private.
bjorn3 commentedon Jun 25, 2025
This uses the same logic for writing the file to a temporary location as
symbols.o
. I guess having a non-deterministic location is harmless in that case as it doesn't contain any functions or data that get linked into the final binary. I could try going back totcx.output_filenames(()).temp_path_for_cgu()
.bjorn3 commentedon Jun 25, 2025
By the way what exactly is this
.so.map
file? What do you use it for? And how exactly is the output.so
different? With incr comp enabled we do use random filenames for object files even before my PR ever since #139453.workingjubilee commentedon Jun 25, 2025
yes, it would be nice if we had an upstream version of your repro test, ideally complete with comments on why.
bjorn3 commentedon Jun 25, 2025
WIP patch which doesn't handle removing the metadata object after linking
10 remaining items