-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Segfault when displaying a error from rusb crate on 32bits #73151
Copy link
Copy link
Closed
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessO-x86_32Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)P-highHigh priorityHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessO-x86_32Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)P-highHigh priorityHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
I tried this code:
Running:
With the following on my Crago.toml:
I expected to see this happen: Cross-compiling to a i686 and running should work on my machine as I do have the required dependencies installed. Both the Debug and Display should be printable without a problem as the type supports both.
Instead, this happened: The type's Display resulted on a "Segmentation fault".
Why do I think this is a rustc issue and not a rusb one
Lower levels of optimization and not using "panic = abort", or setting both on the "profile.dev" didn't cause a panic.
Although the problem is only happening with
rusb::ErrorI have taken a look at it and it doesn't seem to be doing nothing fuzzy.In my tests I did notice that changing the strerror type signature from:
to
Did stop the "Segmentation fault" from happening. But as the type derives
CopyI don't think this should be a problem.I have, however, tried to isolate those piece of code on a isolated example for testing, but I wasn't able to reproduce the problem there, that's why I'm reporting this using rusb itself.
Meta
rustc --version --verbose: