[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Assignees
Labels
arch-wasm
WebAssembly architecture
area-VM-threading-mono
Known Build Error
Use this to report build issues in the .NET Helix tab
os-browser
Browser variant of arch-wasm
Milestone
Comments
pavelsavara
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsSystem.Threading.Tests.MutexTests
|
This was referenced Dec 19, 2023
|
here is one more |
|
I don't see any atomics in store_local, so the stack trace must be wrong |
|
Ah, if so we'd need to run it under a debugger and hope it will pause there |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@lambdageek any thoughts ? |
|
It's either us or emscripten libc, right? Maybe we can instrument all our atomic ops with an alignment check? |
This comment was marked as off-topic.
This comment was marked as off-topic.
pavelsavara
added
the
Known Build Error
|
If we're getting memory access out of bounds, it could mean that we're doing an atomic on a garbage address. That address would have like a 1/2 or 3/4 chance of being unaligned, and a decent chance of being out of bounds. |
|
yeah, maybe we should try building with asan |
|
Couldn't repro locally with debug builds of the runtime/libraries/tests. Trying a release build (but hopefully still with native symbols). Update no luck with release builds either. For the record I'm using: $ ./build.sh --os browser -c Release /p:MonoWasmBuildVariant=multithread /p:KeepNativeSymbols=true /p:WasmNativeDebugSymbols=true /p:MonoEnableAssertMessages=true
...
$ XUNIT_RANDOM_ORDER_SEED=186041091 XHARNESS_COMMAND="test-browser --no-quit --browser=chrome --web-server-use-cop" ./dotnet.sh build /t:Test /p:RuntimeFlavor=Mono /p:WasmEnableThreads=true -c Release /p:TargetOS=browser /p:TargetArchitecture=wasm /p:KeepNativeSymbols=true /p:WasmNativeDebugSymbols=true /p:MonoEnableAssertMessages=true /p:MonoWasmBuildVariant=multithread src/libraries/System.Threading/tests/System.Threading.Tests.csproj
...(Also tried |
have you tried with -fsanitize=address in the cflags/ldflags when building? |
|
|
Any invalid pointer could lead any lock to cause this. |
|
Looking at the emscripten implementation, they don't make any effort to ensure alignment of the address they're doing cas on: https://github.com/emscripten-core/emscripten/blob/e0c3ce6d2b3f121abab481e6e79a1a60e2fcd18b/system/lib/libc/musl/src/thread/pthread_mutex_trylock.c#L75 So not only would invalid pointers have a 3/4 or 7/8 chance of hitting this, but you need to make sure any pthread_mutex_t instances are sufficiently aligned as well - if they're static you're relying on the linker to arrange them at aligned offsets (it probably has to for anything to work), and if they're struct members you're relying on the alignment and packing of the struct to not put it at a bad address. If you're trying to lock an invalid pointer, I would assume that in cases where it doesn't crash like this, it either erroneously wakes instantly because it thinks it just 'locked' garbage memory, or it deadlocks forever waiting on something that isn't a lock? |
|
|
|
|
|
|
|
This could be just another manifestation of the MT corruption we're seeing other places where the invalid address is unaligned |
|
Log with dumped worker info: |
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Error Blob
{ "ErrorMessage": "RuntimeError: operation does not support unaligned accesses", "BuildRetry": false, "ErrorPattern": "", "ExcludeConsoleLog": false }Reproduction Steps
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=556904&view=logs&jobId=63c2d0c8-fec2-5788-81c8-f3ac95e8841f
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=556904
Error message validated:
RuntimeError: operation does not support unaligned accessesResult validation: ✅ Known issue matched with the provided build.
Validation performed at: 2/7/2024 4:03:46 PM UTC
Report
Summary
The text was updated successfully, but these errors were encountered: