-
Notifications
You must be signed in to change notification settings - Fork 26
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
Support for 32-bit architectures #8
Comments
Hi Adam, there's no fundamental reason why it shouldn't work on 32-bit - just that I don't have a 32-bit system to test it on and there's a lot of unsafe in there so I added the compile-time pointer size check more as a safeguard against someone trying to use it on a system I hadn't tested at all and something awful happening. It may even work OOTB if you remove the check as I don't think I explicity assume the size of a pointer is 8 bytes anywhere. You might want to just try removing that check and running the tests (make sure you do so with RUST_TEST_THREADS=1) to see what happens. I'm happy to guide you through any issues you might encounter. |
Ah yeah, I did do that, and it caught some kind of UB, but I didn't really know how to read the message and track down the error:
Another thing that I'm concerned about is the assumption of the layout of a |
So I think there are some assumptions made in At the moment, I've decided to use a |
Yep I've found the issue in this case. I think StringCache it's actually fine, it was the Ustr::precomputed_hash() accessor was assuming that that the hash was 16 bytes before the characters which won't be true on a 32-bit platform. Could you try pulling and running the tests again please? |
The miri tests pass on i686 now, though I'm not convinced that your solution is completely sound. It's not clear that the |
Thanks for checking! Yes indeed correct alignment is guaranteed by the
allocator. I'll update the comments to match. In fact what I'll probably do
is move the conversion from char* to StringCacheEntry* to a dedicated
method so that precomputed_hash() and len() can both be safe wrappers
around it.
…On Tue, 7 Apr 2020 at 09:18, Adam Gausmann ***@***.***> wrote:
The miri tests pass on i686 now, though I'm not convinced that your
solution is completely sound. It's not clear that the *const u64 is
properly aligned in all cases from the perspective of Ustr. I guess if
StringCacheEntrys are always placed at aligned locations (which both the
allocator and StringCacheEntry::next_entry seem to guarantee), then it
should be okay. Might be a good idea to address that in the relevant safety
comments though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOYQXKO4B64WOW2OGY4XDLRLJBKBANCNFSM4L5L6H6Q>
.
|
32-bit crashes randomly with STATUS_ACCESS_VIOLATION on heavy multithreaded workloads in my application. I'm pretty sure It's Ustr because when I changed all of the Strings from Ustr to String everything is fine. Also everything is fine with 64bit. |
Sorry for the delayed response here. Do you have an idea of how many strings are being created by your application? |
I would love to be able to use ustr for my WebAssembly project, but it is a 32-bit architecture. What are the blockers for supporting 32-bit?
The text was updated successfully, but these errors were encountered: