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

Panic in std #127563

Closed
Trini7 opened this issue Jul 10, 2024 · 8 comments · Fixed by #127583
Closed

Panic in std #127563

Trini7 opened this issue Jul 10, 2024 · 8 comments · Fixed by #127583
Labels
C-bug Category: This is a bug. O-linux Operating system: Linux T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@Trini7
Copy link

Trini7 commented Jul 10, 2024

version: nightly-2023-11-22
os: centos-7

panic:
thread '' panicked at library/std/src/sys/unix/net.rs:50:76:
called Result::unwrap() on an Err value: Utf8Error { valid_up_to: 4, error_len: Some(1) }
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
thread '' panicked at library/std/src/sys/unix/net.rs:50:76:
called Result::unwrap() on an Err value: Utf8Error { valid_up_to: 4, error_len: Some(1) }
thread '' panicked at library/std/src/sys/unix/net.rs:50:76:
called Result::unwrap() on an Err value: Utf8Error { valid_up_to: 4, error_len: Some(1) }
thread '' panicked at library/std/src/sys/unix/net.rs:50:76:
called Result::unwrap() on an Err value: Utf8Error { valid_up_to: 4, error_len: Some(1) }

@Trini7 Trini7 added the C-bug Category: This is a bug. label Jul 10, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 10, 2024
@bjorn3
Copy link
Member

bjorn3 commented Jul 10, 2024

You are using a nightly that is over half a year old. Try using the latest nightly to see if it reproduces. If it does, please set RUST_BACKTRACE=1 and report back the printed backtrace as well as the project on which you get this panic.

@Trini7
Copy link
Author

Trini7 commented Jul 10, 2024

Based on my testing, the latest version also has this issue.

@eggyal
Copy link
Contributor

eggyal commented Jul 10, 2024

It would appear that your libc's gai_strerror function is not returning a UTF-8 encoded string (the fourth byte is invalid).

@Noratrieb Noratrieb added O-linux Operating system: Linux T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jul 10, 2024
@Noratrieb
Copy link
Member

Can you share some of your system config, especially your locale? gai_strerror returning invalid UTF-8 is certainly not something expected by std.

@Trini7
Copy link
Author

Trini7 commented Jul 10, 2024

image

@Noratrieb
Copy link
Member

Which Chinese locale exactly? Could you show the values of the LC_ environment variables?

@Trini7
Copy link
Author

Trini7 commented Jul 10, 2024

Sorry, the environment is no longer available, but it seems that using unwrap in net.rs:50:76 is too risky.

@Noratrieb
Copy link
Member

Noratrieb commented Jul 10, 2024

It's probably not a UTF-8 locale. I would really recommend changing your locale to a UTF-8 one if possible, then this should work again.
But you're right, this unwrap shouldn't be there, normal strerror uses from lossy, which will give a bad error but at least won't crash. I'll send a PR.

// We can't always expect a UTF-8 environment. When we don't get that luxury,
// it's better to give a low-quality error message than none at all.
String::from_utf8_lossy(CStr::from_ptr(p).to_bytes()).into()

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jul 21, 2024
Deal with invalid UTF-8 from `gai_strerror`

When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.

We already do this for `strerror_r`.

fixes rust-lang#127563
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 21, 2024
Deal with invalid UTF-8 from `gai_strerror`

When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.

We already do this for `strerror_r`.

fixes rust-lang#127563
@bors bors closed this as completed in 6af66e8 Jul 22, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 22, 2024
Rollup merge of rust-lang#127583 - Nilstrieb:invalid-utf8, r=joboet

Deal with invalid UTF-8 from `gai_strerror`

When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.

We already do this for `strerror_r`.

fixes rust-lang#127563
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. O-linux Operating system: Linux T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants