Instrumentation profile data contains empty function name (?) as of nightly-2025-05-19

[jan-ferdinand]

Hi there! I hope I'm using the right issue template and the right repository; apologies if I'm not. Happy about pointers to improve on that.
Also, the issue's title might be arbitrarily far from what's actually going on.

Code

I tried to run the following command on this crate:

cargo llvm-cov

I expected to see this happen: successful generation of a coverage report, for example like in this workflow run.

Instead, this happened: error “malformed instrumentation profile data: function name is empty”, for example like in this workflow run.

I can reproduce the error locally, so I'm reasonably sure that it's not CI's fault.

Version it worked on

rustc --version --verbose:

rustc 1.89.0-nightly (4d051fb30 2025-05-18)
binary: rustc
commit-hash: 4d051fb306e661654d088892e02e69b8c0c39d43
commit-date: 2025-05-18
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

Version with regression

rustc --version --verbose:

rustc 1.89.0-nightly (60dabef95 2025-05-19)
binary: rustc
commit-hash: 60dabef95a3de3ec974dcb50926e4bfe743f078f
commit-date: 2025-05-19
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

I have tried to run cargo-bisect-rustc but can't get the installation of the component llvm-tools-preview to work there, since the toolchain bisect-* seems to be throwing something off. 😕

[apiraino]

@jan-ferdinand thanks for filing this issue. is it possible to reproduce the issue without having the code in that repository connect to external services?

Details

2025-05-26T11:00:46.407357Z DEBUG neptune_cash::tests::shared: cannot open file 'test_data/6770875a59dc73f6c82631f771c44db8ce2444a71c3eacdb66e337be1e2a8ab3440f365c8449f85f.proof' -- might not exist
2025-05-26T11:00:46.407372Z DEBUG neptune_cash::models::proof_abstractions::tasm::program::tests: Proof not found on disk.
2025-05-26T11:00:46.407590Z DEBUG neptune_cash::tests::shared: requesting: <http://explorer.neptune.cash:42580/6770875a59dc73f6c82631f771c44db8ce2444a71c3eacdb66e337be1e2a8ab3440f365c8449f85f.proof>
http://explorer.neptune.cash:42580/ responded with 404 Not Found
2025-05-26T11:00:46.913707Z DEBUG neptune_cash::tests::shared: requesting: <http://neptunefundamentals.org:42580/6770875a59dc73f6c82631f771c44db8ce2444a71c3eacdb66e337be1e2a8ab3440f365c8449f85f.proof>
got proof.

Note, for info: llvm-cov is a separate project hosted at https://github.com/taiki-e/cargo-llvm-cov

@rustbot label +E-needs-bisection +E-needs-mcve

[bjorn3]

Same issue with zlib-rs: trifectatechfoundation/zlib-rs#368 cc @folkertdev

[jan-ferdinand]

is it possible to reproduce the issue without having the code in that repository connect to external services?

Apologies! It is possible, yes:

works: cargo +nightly-2025-05-19 llvm-cov -- database::storage::storage_schema::dbtvec::tests::streams::stream_many
doesn't work: cargo +nightly-2025-05-20 llvm-cov -- database::storage::storage_schema::dbtvec::tests::streams::stream_many

Note, for info: llvm-cov is a separate project hosted at taiki-e/cargo-llvm-cov

Thanks for pointing this out explicitly. The reason I opened the issue here is that, as far as I can tell, the same version of llvm-cov is being used in both the working and the failing command. If you think the issue belongs with llvm-cov, I can move the discussion there.

[folkertdev]

I would guess #141063 is the cause?

[jan-ferdinand]

I would guess #141063 is the cause?

According to rustc --version --verbose, both the working and the failing command use the same version of LLVM, namely 20.1.5.

$ diff -u fails works
-rustc 1.89.0-nightly (60dabef95 2025-05-19)
+rustc 1.89.0-nightly (4d051fb30 2025-05-18)
 binary: rustc
-commit-hash: 60dabef95a3de3ec974dcb50926e4bfe743f078f
-commit-date: 2025-05-19
+commit-hash: 4d051fb306e661654d088892e02e69b8c0c39d43
+commit-date: 2025-05-18
 host: x86_64-unknown-linux-gnu
 release: 1.89.0-nightly
 LLVM version: 20.1.5

[folkertdev]

Maybe #140847 then (cc @Zalathar does that seem plausible)?

I can't reproduce the issue locally, we're only seeing it on CI. @jan-ferdinand what is your problem with cargo bisect-rustc? Maybe you could use a custom script and run e.g. this to install the right llvm-cov?

rustup +nightly-2025-05-19-x86_64-unknown-linux-gnu component add llvm-tools-preview

[bjorn3]

You can pass -c llvm-tools-preview to cargo bisect-rustc to tell it to install this component for every toolchain it downloads.

[jan-ferdinand]

I can't reproduce the issue locally

That's a bummer, @folkertdev. Do you have any idea how I could help you out here?

edit: Oh, I might have misunderstood what you're saying. Are you saying that you cannot reproduce trifectatechfoundation/zlib-rs#368 locally?

what is your problem with cargo bisect-rustc?

• The toolchain set by bisect-rustc is bisect-nightly-_, and I don't know how to teach rustup that the bisect- prefix should be ignored when I tell it to install a component. It keeps telling me that I'm supplying an invalid toolchain name, which… yeah, I am. My assumption is that simply trimming the prefix myself installs the component for a different toolchain than the bisect-_ one. Perhaps that's an incorrect assumption?
• I thought about using a custom script. However, from my understanding, such scripts should not set the toolchain themselves but rather rely on bisect-rustc's overrides. My intuition tells me that doing rustup +my-toolchain in the custom script would interfere with the bisection process. This understanding could be arbitrarily flawed. Is your suggestion a good way forward?

You can pass -c llvm-tools-preview to cargo bisect-rustc to tell it to install this component for every toolchain it downloads.

That sounds useful, @bjorn3.¹ Unfortunately, I can't get it to work. Apparently, the requested version of the toolchain could not be found. I'm assuming it means that the requested component could not be found? The same is true if I try different dates for --start. I want back as far as 2025-05-15 and then concluded that it's a systematic problem.

Console Dump

❯ cargo bisect-rustc -c llvm-tools-preview --start=2025-05-19 --end=2025-05-20 -- llvm-cov -- database::storage::storage_schema::dbtvec::tests::streams::stream_many
checking the start range to find a passing nightly
installing nightly-2025-05-19
cargo-nightly-x86_64-unknown-linux-gnu: 9.55 MB / 9.55 MB
…
uninstalling nightly-2025-05-19
*** unable to install nightly-2025-05-19. roll back one day and try again...
ERROR: could not find nightly-2025-05-19

Omitting the -c llvm-tools-preview results in a compilation error. It makes sense to me that something fails if a required component is missing.

Console Dump

❯ cargo bisect-rustc --start=2025-05-19 --end=2025-05-20 -- llvm-cov -- database::storage::storage_schema::dbtvec::tests::streams::stream_many
checking the start range to find a passing nightly
installing nightly-2025-05-19
rust-std-nightly-x86_64-unknown-linux-gnu: …
RESULT: nightly-2025-05-19, ===> Compile error
uninstalling nightly-2025-05-19
ERROR: the start of the range (nightly-2025-05-19) must not reproduce the regression

Footnotes

1. Is there a secret piece of documentation flying around other than the cargo-bisect-rustc book? ↩

[Zalathar]

Maybe #140847 then (cc @Zalathar does that seem plausible)?

It would be weird, but not completely implausible.

Given the circumstances, I think I'll try a revert.

[Zalathar]

The revert has been merged (#141650), so hopefully the failure will disappear in the next nightly. Please let me know whether or not that's the case.

That said, I do intend to re-land similar changes at some point in the future. So without a self-contained repro (or at least knowing what actually happened here), there is a risk that this will break again.

[apiraino]

thanks @Zalathar

I'll assign this issue to you for further investigation (but feel free to re-assign or just unassign)

@rustbot assign @Zalathar

[folkertdev]

Looks like the revert did indeed fix the issue, zlib-rs CI is passing again https://github.com/trifectatechfoundation/zlib-rs/actions/runs/15338976180.

zlib-rs is happy to be the canary in the coalmine here for future changes (that's kind of what nightly is for). I've still not been able to reproduce the issue locally, maybe @jan-ferdinand can make a smaller reproducing example?