Skip to content

Panic in std #127563

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # 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