-
Notifications
You must be signed in to change notification settings - Fork 13k
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
memrchr uses unaligned loads #35967
Comments
The crash is a SIGBUS (which is usually caused by unaligned loads), so this is likely the cause. If anyone want to find more, the exact location is |
If you have the time, you can try with the posted PR #35969 to verify the fix. |
memrchr: Correct aligned offset computation The memrchr fallback did not compute the offset correctly. It was intentioned to land on usize-aligned addresses but did not. This was suspected to have resulted in a crash on ARMv7! This bug affected non-linux platforms. I think like this, if we have a slice with pointer `ptr` and length `len`, we want to find the last usize-aligned offset in the slice. The correct computation should be: For example if ptr = 1 and len = 6, and `size_of::<usize>()` is 4: ``` [ x x x x x x ] 1 2 3 4 5 6 ^-- last aligned address at offset 3 from the start. ``` The last aligned address is ptr + len - (ptr + len) % usize_size. Compute offset from the start as: offset = len - (ptr + len) % usize_size = 6 - (1 + 6) % 4 = 6 - 3 = 3. I believe the function's return value was always correct previously, if the platform supported unaligned addresses. Fixes #35967
@tomaka how relevant is this platform for stable rust? Should we beta-nominate the fix? |
The crash disappeared after the latest nightly. |
Thank you |
Due to an arithmetic error, the fallback memrchr (used for non-linux) in libstd uses unaligned loads, the intention was to produce only well aligned pointers of course.
This was suspected to cause a crash using ARMv7, found by @tomaka
Original code also had the same issue: BurntSushi/memchr/pull/9
I believe that on x86 non-linux platforms, the bug was harmless and the function still produced the correct return value.
The text was updated successfully, but these errors were encountered: