Panic in std

[Trini7]

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) }

[bjorn3]

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]

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

[eggyal]

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

[Noratrieb]

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]

[Noratrieb]

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

[Trini7]

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

[Noratrieb]

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. https://github.com/rust-lang/rust/blob/b215beb567857000fdaa868cbb78702bc5ee0ee9/library/std/src/sys/pal/unix/os.rs#L135-L137