dladdr cannot leave dli_fname to be null#141239
Merged
bors merged 1 commit intorust-lang:masterfrom May 19, 2025
Merged
Conversation
Collaborator
|
rustbot has assigned @compiler-errors. Use |
Collaborator
|
The Miri subtree was changed cc @rust-lang/miri |
RalfJung
commented
May 19, 2025
| fn get_func_ptr_explicitly_from_lib(&mut self, link_name: Symbol) -> Option<CodePtr> { | ||
| let this = self.eval_context_mut(); | ||
| // Try getting the function from the shared library. | ||
| // On windows `_lib_path` will be unused, hence the name starting with `_`. |
Member
Author
There was a problem hiding this comment.
This comment was outdated, the entire module does not even get built on Windows.
Member
|
@bors r+ |
Collaborator
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 19, 2025
Rollup of 5 pull requests Successful merges: - rust-lang#140847 (coverage: Detect unused local file IDs to avoid an LLVM assertion) - rust-lang#141117 (opt-dist: fix deprecated BOLT -icf=1 option) - rust-lang#141225 (more ice tests) - rust-lang#141239 (dladdr cannot leave dli_fname to be null) - rust-lang#141242 (in `tests/ui/asm/aarch64/parse-error.rs`, only test cases specific to that target) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 19, 2025
Rollup merge of rust-lang#141239 - RalfJung:dladdr-fname, r=Noratrieb dladdr cannot leave dli_fname to be null There are two places in the repo calling `dladdr`, and they are inconsistent wrt their assumption of whether the `dli_fname` field can be null. Let's make them consistent. I see nothing in the docs that allows it to be null, but just to be on the safe side let's make this an assertion so hopefully we get a report if that ever happens.
jeremyd2019
reviewed
May 19, 2025
| if info.dli_fname.is_null() { | ||
| return Err("dladdr returned null pointer".into()); | ||
| } | ||
| assert!(!info.dli_fname.is_null(), "the docs do not allow dladdr to be null"); |
Contributor
There was a problem hiding this comment.
maybe "do not allow dli_fname to be null" ? as you pointed out, dladdr can return 0, and dli_sname can be null.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
May 20, 2025
…rieb current_dll_path: fix mistake in assertion message Follow-up to rust-lang#141239 r? `@Noratrieb`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 20, 2025
Rollup merge of rust-lang#141261 - RalfJung:current_dll_path, r=Noratrieb current_dll_path: fix mistake in assertion message Follow-up to rust-lang#141239 r? `@Noratrieb`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There are two places in the repo calling
dladdr, and they are inconsistent wrt their assumption of whether thedli_fnamefield can be null. Let's make them consistent. I see nothing in the docs that allows it to be null, but just to be on the safe side let's make this an assertion so hopefully we get a report if that ever happens.