Emscripten: Alignment fault or index out of bound error with wasm

[tanis2000]

I have a simple project written in Rust that I'm trying to run in the browser through emscripten. On Rust's side I'm using cargo web which in turn calls out to emscripten to compile my project to wasm.

I noticed that if I turn on SAFE_HEAP, I get the following error:

Uncaught abort("alignment fault") at Error
    at jsStackTrace (http://localhost:8000/main.js:1667:13)
    at stackTrace (http://localhost:8000/main.js:1684:12)
    at abort (http://localhost:8000/main.js:11888:44)
    at alignfault (http://localhost:8000/main.js:1053:3)
    at SAFE_HEAP_LOAD_i32_4_4 (wasm-function[171210]:39)
    at __ZN4core4cell13Cell_LT_T_GT_3get17ha7292d0f274620b2E (wasm-function[3605]:45)
    at __ZN5alloc2rc8RcBoxPtr6strong17h9d76bc796af30b74E (wasm-function[1084]:51)
    at __ZN5alloc2rc8RcBoxPtr10inc_strong17h974f8b274d2ef40bE (wasm-function[1089]:36)
    at __ZN61__LT_alloc__rc__Rc_LT_T_GT__u20_as_u20_core__clone__Clone_GT_5clone17h42ec3c5edf9a6750E (wasm-function[1102]:36)
    at dynCall_ii (wasm-function[5737]:14)

I understand that this might be a false alarm as memory alignment isn't actually required for wasm but rather for asm.js, so I turn it off but I get the following error:

exception thrown: RuntimeError: index out of bounds,__ZN4core5slice6memchr6memchr17h34af94afc06c5321E@http://localhost:8000/main.wasm:wasm-function[1257]:0x62af2
__ZN81__LT_core__str__pattern__CharSearcher_u20_as_u20_core__str__pattern__Searcher_GT_10next_match17hc1707b766f0502daE@http://localhost:8000/main.wasm:wasm-function[883]:0x4596d
__ZN4core3str29MatchIndicesInternal_LT_P_GT_4next17h1dff6cb86e588192E@http://localhost:8000/main.wasm:wasm-function[831]:0x428a6
__ZN91__LT_core__str__MatchIndices_LT_P_GT__u20_as_u20_core__iter__traits__iterator__Iterator_GT_4next17h145cf846703825c7E@http://localhost:8000/main.wasm:wasm-function[834]:0x42a53
dynCall_vii@http://localhost:8000/main.wasm:wasm-function[2264]:0x1839e7
Module.dynCall_vii@http://localhost:8000/main.js:10995:39
invoke_vii@http://localhost:8000/main.js:10133:5
__ZN5alloc3str21__LT_impl_u20_str_GT_7replace17h4474238dc3cfeeaeE@http://localhost:8000/main.wasm:wasm-function[881]:0x451bb
__ZN4sdl23log3log17hdf3b9889906e108cE@http://localhost:8000/main.wasm:wasm-function[725]:0x3f155
__ZN4main4main28__u7b__u7b_closure_u7d__u7d_17hb104fc522ce8ab7eE@http://localhost:8000/main.wasm:wasm-function[517]:0x3604b
__ZN4main22set_main_loop_callback7wrapper28__u7b__u7b_closure_u7d__u7d_17h9869454d3a2bbdcdE@http://localhost:8000/main.wasm:wasm-function[516]:0x35fdf
dynCall_vi@http://localhost:8000/main.wasm:wasm-function[2259]:0x183972
Module.dynCall_vi@http://localhost:8000/main.js:10965:38
invoke_vi@http://localhost:8000/main.js:10122:5
__ZN3std6thread5local17LocalKey_LT_T_GT_8try_with17h56abda4a92774cf4E@http://localhost:8000/main.wasm:wasm-function[346]:0x2dfef
__ZN3std6thread5local17LocalKey_LT_T_GT_4with17h182ac366d6efc19cE@http://localhost:8000/main.wasm:wasm-function[345]:0x2dde3
__ZN4main22set_main_loop_callback7wrapper17h4e0b54fbd41c9f35E@http://localhost:8000/main.wasm:wasm-function[514]:0x35e16
dynCall_v@http://localhost:8000/main.wasm:wasm-function[2254]:0x183909
Module.dynCall_v@http://localhost:8000/main.js:10935:37
browserIterationFunc@http://localhost:8000/main.js:5938:18
runIter@http://localhost:8000/main.js:6056:13
Browser_mainLoop_runner@http://localhost:8000/main.js:5994:26

I can't understand what's going on, it feels like there's a problem with the way memory is being handled but I really don't know where to look at. Any help would be really appreciated.

[VirtualTim]

In my experience with c++ compiling with -s SAFE_HEAP=1 -s WARN_UNALIGNED=1, and the clang/gcc compile options -Wcast-align -Wover-aligned helps highlight issues. Maybe Rust has an equevelant?

Not sure how Rust name mangling works, but look at whatever _ZN4core4cell13Cell_LT_T_GT_3get17ha7292d0f274620b2E demangles to, and analyse the loads in that function.
That should get you the line that's throwing, but without seeing source code I have no idea why.

Hope that at least points you in the right direction?

[tanis2000]

Thanks for the reply @VirtualTim ! The SAFE_HEAP and WARN_UNALIGNED can both be applied and I'm actually using them. I'm also demangling the function names so that it's clearer to see where it's breaking. The con is that it's breaking pretty much anywhere, it's not just a single function that's showing this issue.. just leave the app running for a while and you end up with one of those error.

i.e. this is a segmentation fault that just happened:

uncaught exception: abort("segmentation fault") at jsStackTrace@http://localhost:8000/main.js:1691:13
stackTrace@http://localhost:8000/main.js:1708:12
abort@http://localhost:8000/main.js:11509:44
segfault@http://localhost:8000/main.js:1052:3
SAFE_HEAP_LOAD_i32_1_1@http://localhost:8000/main.wasm:wasm-function[58881]:0x258041
core::slice::memchr::memrchr::hf02d9bb6e98bf7d7 [__ZN4core5slice6memchr7memrchr17hf02d9bb6e98bf7d7E]@http://localhost:8000/main.wasm:wasm-function[1475]:0x7e535
dynCall_viiii@http://localhost:8000/main.wasm:wasm-function[2696]:0x1dcbfa
Module.dynCall_viiii@http://localhost:8000/main.js:11182:41
invoke_viiii@http://localhost:8000/main.js:10292:5
__LT_std__io__stdio__StdoutLock_u20_as_u20_std__io__Write_GT_::write::hec05a3b27fb154cf [__ZN61__LT_std__io__stdio__StdoutLock_u20_as_u20_std__io__Write_GT_5write17hec05a3b27fb154cfE]@http://localhost:8000/main.wasm:wasm-function[1376]:0x6e839
std::io::Write::write_all::h8c6f652a428d6005 [__ZN3std2io5Write9write_all17h8c6f652a428d6005E]@http://localhost:8000/main.wasm:wasm-function[1380]:0x6f17a
__LT_std__io__Write__write_fmt__Adaptor_LT_T_GT__u20_as_u20_core__fmt__Write_GT_::write_str::h832840808ac9a9cc [__ZN80__LT_std__io__Write__write_fmt__Adaptor_LT_T_GT__u20_as_u20_core__fmt__Write_GT_9write_str17h832840808ac9a9ccE]@http://localhost:8000/main.wasm:wasm-function[1383]:0x6f8ee
core::fmt::Formatter::pad::hd51f0fa9e8782b07 [__ZN4core3fmt9Formatter3pad17hd51f0fa9e8782b07E]@http://localhost:8000/main.wasm:wasm-function[1447]:0x7af57
__LT_str_u20_as_u20_core__fmt__Display_GT_::fmt::h6cd70c1fc6d3156f [__ZN42__LT_str_u20_as_u20_core__fmt__Display_GT_3fmt17h6cd70c1fc6d3156fE]@http://localhost:8000/main.wasm:wasm-function[1513]:0x833a1
__LT__RF_T_u20_as_u20_core__fmt__Display_GT_::fmt::h25affbb719f00514 [__ZN44__LT__RF_T_u20_as_u20_core__fmt__Display_GT_3fmt17h25affbb719f00514E]@http://localhost:8000/main.wasm:wasm-function[1133]:0x5fca4
core::fmt::write::h9f284ae8e8e9b94a [__ZN4core3fmt5write17h9f284ae8e8e9b94aE]@http://localhost:8000/main.wasm:wasm-function[1457]:0x7cb18
dynCall_iiii@http://localhost:8000/main.wasm:wasm-function[2673]:0x1dc9bd
Module.dynCall_iiii@http://localhost:8000/main.js:11044:40
invoke_iiii@http://localhost:8000/main.js:10215:12
__LT_std__io__stdio__Stdout_u20_as_u20_std__io__Write_GT_::write_fmt::h3045bdd941d397cd [__ZN57__LT_std__io__stdio__Stdout_u20_as_u20_std__io__Write_GT_9write_fmt17h3045bdd941d397cdE]@http://localhost:8000/main.wasm:wasm-function[1381]:0x6f583
dynCall_viii@http://localhost:8000/main.wasm:wasm-function[2695]:0x1dcbe1
Module.dynCall_viii@http://localhost:8000/main.js:11176:40
invoke_viii@http://localhost:8000/main.js:10281:5
std::io::stdio::_print::h0c4cd85c62ff2d7d [__ZN3std2io5stdio6_print17h0c4cd85c62ff2d7dE]@http://localhost:8000/main.wasm:wasm-function[1390]:0x70121
main::main::__u7b__u7b_closure_u7d__u7d_::h978d1b19726a4a9b [__ZN4main4main28__u7b__u7b_closure_u7d__u7d_17h978d1b19726a4a9bE]@http://localhost:8000/main.wasm:wasm-function[558]:0x45027
main::set_main_loop_callback::wrapper::__u7b__u7b_closure_u7d__u7d_::h60fcdedd5eb884db [__ZN4main22set_main_loop_callback7wrapper28__u7b__u7b_closure_u7d__u7d_17h60fcdedd5eb884dbE]@http://localhost:8000/main.wasm:wasm-function[557]:0x44f42
dynCall_vi@http://localhost:8000/main.wasm:wasm-function[2688]:0x1dcb3e
Module.dynCall_vi@http://localhost:8000/main.js:11134:38
invoke_vi@http://localhost:8000/main.js:10259:5
std::thread::local::LocalKey_LT_T_GT_::try_with::hdb30b02697fc3000 [__ZN3std6thread5local17LocalKey_LT_T_GT_8try_with17hdb30b02697fc3000E]@http://localhost:8000/main.wasm:wasm-function[368]:0x3b1b3
std::thread::local::LocalKey_LT_T_GT_::with::h45e6cfb1718cea22 [__ZN3std6thread5local17LocalKey_LT_T_GT_4with17h45e6cfb1718cea22E]@http://localhost:8000/main.wasm:wasm-function[367]:0x3af92
main::set_main_loop_callback::wrapper::hb6245503f59d030f [__ZN4main22set_main_loop_callback7wrapper17hb6245503f59d030fE]@http://localhost:8000/main.wasm:wasm-function[555]:0x44d3d
dynCall_v@http://localhost:8000/main.wasm:wasm-function[2683]:0x1dcad5
Module.dynCall_v@http://localhost:8000/main.js:11104:37
browserIterationFunc@http://localhost:8000/main.js:6064:18
runIter@http://localhost:8000/main.js:6182:13
Browser_mainLoop_runner@http://localhost:8000/main.js:6120:26

All that the main loop is doing right now is allocate a function-local array of 1.000.000 int32, print a string to stdout and reiterate.

I would think that this might just be some sort of memory leaking but if I check the memory allocation in the profiler it sits at around 21Mb and I set ALLOW_MEMORY_GROWTH=1 so that shouldn't really be an issue.
It's more like something is corrupting the memory or something like that.

I don't know what the -Wcast-align -Wover-aligned flags do exactly. As far as I can tell Rust aligns memory based on the ABI it's compiling to, so there is no way to tell the compiler how to align memory unless you do it manually for each and every struct in your code (and Rust's std library and so on) so it's pretty much out of discussion.

[VirtualTim]

-Wcast-align Warns you if you do something like

char* test;
int* test2 = (int*)test;

where a char is 1 byte, and int is 4 bytes.
This is the kind of thing that works with native code, but will probably fail on Emscripten.

You could try disabling ALLOW_MEMORY_GROWTH, if Emscripten fails to alloc it'll throw an OOM error (assuming ABORTING_MALLOC=1, the default).

I've had issues in the past where an unaligned write (or write to an uninitialised pointer) corrupted program memory, and then later on caused issues. But if that was the case SAFE_HEAP should be throwing a segfault on write. So I'm not sure.

If you can reproduce this with just a simple loop could you post your code? I have no Rust experience, but someone else may be able to spot what's going wrong.

[tanis2000]

That makes sense and sounds like the kind of issue I'm experiencing. The problem is that I can't reproduce this with a simple C project as all of my plain C projects work fine with Emscripten and I've never had this kind of issue so far. It happens only with Rust and I don't know anything about the internals of the Rust compiler in order to understand what's happening under the hood.

I guess I'll have to cross-check this information with someone on the Rust language team so that I can figure out what's going on. Thank you so much for the help so far!

[Y0QIN]

I meet the same error on C wasm project.
somebody has any solution about this problem?

[tanis2000]

@Y0QIN with C you just have to do what @VirtualTim suggested. Make sure you’re not assigning variables of different sizes or uninitialized pointers

[Y0QIN]

I used ffmpeg to decode mystream，and the error occured at function av_new_packet which was compiled by emcc from ffmpeg code

[tanis2000]

Can you compile this to wasm without optimizations and with debug symbols so that you can track which line in av_new_packet is causing the error?

[Y0QIN]

@tanis2000 you means to compile ffmpeg without optimizations ?

[tanis2000]

Yes, exactly. Make sure you disable optimizations in emscripten

[VirtualTim]

At a minimum I'd suggest compiling with -fno-inline -fno-inline-functions --profiling and linking with -s DEMANGLE_SUPPORT=1.
This will get you a much nicer stack trace.

[tlively]

It's possible the original report here was a Rust bug that has since been fixed. I know it's old, but @tanis2000 are you still seeing problems? If you have Rust+Emscripten bugs please cc me on them so I see them and can investigate further.

[tanis2000]

@tlively the original bug has been fixed by the Rust guys some time ago indeed. Nowadays it’s working fine.

[VirtualTim]

@Y0QIN I'm closing this issue, since it has been fixed in Rust. If you're still seeing your issue can you create a separate bug?

[Y0QIN]

@VirtualT thank you. I fixed this issue finally,since there was assigning variables of different sizes in my c files

[VirtualTim]

Out of curiosity, how did you figure that one out? Did -Wcast-align point out the problem?

[Y0QIN]

Acually -Wcast-align didn't point out the problem，I don't konw why this happend.
In my case ,it occured this problem more frequently when I decode high resolution video then low resolution ， then I found it by code review