Simulate OOM for the try_oom_error test by cuviper · Pull Request #138370 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation3 Commits1 Checks6 Files changed

Conversation

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

[ Show hidden characters]({{ revealButtonHref }})

cuviper

We can create the expected error manually, rather than trying to produce
a real one, so the error conversion test can run on all targets. Before,
it was only running on 64-bit and not miri.

In Fedora, we also found that s390x was not getting the expected error,
"successfully" allocating the huge size because it was optimizing the
real malloc call away. It's possible to counter that by looking at the
pointer in any way, like a debug print, but it's more robust to just
deal with errors directly, since this test is only about conversion.

Related: #133806

@cuviper

We can create the expected error manually, rather than trying to produce a real one, so the error conversion test can run on all targets. Before, it was only running on 64-bit and not miri.

In Fedora, we also found that s390x was not getting the expected error, "successfully" allocating the huge size because it was optimizing the real malloc call away. It's possible to counter that by looking at the pointer in any way, like a debug print, but it's more robust to just deal with errors directly, since this test is only about conversion.

@rustbot

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Mar 11, 2025

@jhpratt

@bors

📌 Commit 53f488a has been approved by jhpratt

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Mar 13, 2025

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Mar 13, 2025

@matthiaskrgr

Simulate OOM for the try_oom_error test

We can create the expected error manually, rather than trying to produce a real one, so the error conversion test can run on all targets. Before, it was only running on 64-bit and not miri.

In Fedora, we also found that s390x was not getting the expected error, "successfully" allocating the huge size because it was optimizing the real malloc call away. It's possible to counter that by looking at the pointer in any way, like a debug print, but it's more robust to just deal with errors directly, since this test is only about conversion.

Related: rust-lang#133806

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 13, 2025

@bors

…iaskrgr

Rollup of 9 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 13, 2025

@bors

…iaskrgr

Rollup of 8 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Mar 13, 2025

@rust-timer

Rollup merge of rust-lang#138370 - cuviper:try_oom_error, r=jhpratt

Simulate OOM for the try_oom_error test

We can create the expected error manually, rather than trying to produce a real one, so the error conversion test can run on all targets. Before, it was only running on 64-bit and not miri.

In Fedora, we also found that s390x was not getting the expected error, "successfully" allocating the huge size because it was optimizing the real malloc call away. It's possible to counter that by looking at the pointer in any way, like a debug print, but it's more robust to just deal with errors directly, since this test is only about conversion.

Related: rust-lang#133806

github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request

Mar 14, 2025

@matthiaskrgr

Simulate OOM for the try_oom_error test

We can create the expected error manually, rather than trying to produce a real one, so the error conversion test can run on all targets. Before, it was only running on 64-bit and not miri.

In Fedora, we also found that s390x was not getting the expected error, "successfully" allocating the huge size because it was optimizing the real malloc call away. It's possible to counter that by looking at the pointer in any way, like a debug print, but it's more robust to just deal with errors directly, since this test is only about conversion.

Related: rust-lang#133806

Labels

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.