platform icon indicating copy to clipboard operation
platform copied to clipboard

bug(dpp): Wasm SIMD unsupported

Open pshenmic opened this issue 2 years ago • 1 comments

Expected Behavior

Wasm DPP should be able to run on all systems

Current Behavior

On some specific CPUs, WASM DPP couldn't be run successfully due missing instructions:

CompileError: WebAssembly.Module(): Compiling function https://github.com/dashpay/platform/pull/331:"memchr::arch::wasm3 2::simd128::packedpair::Find..." failed: Wasm SIMD unsupported @+1955693

Possible Solution

Revise changes happened between 0.25.13 and 0.25.15

Steps to Reproduce (for bugs)

git clone https://github.com/pshenmic/wasm-dpp-nodejs-load-sample
cd wasm-dpp-nodejs-load-sample
npm install
node index

Context

https://github.com/dashpay/platform/issues/1583 have more some more details.

Basically, that happened on the 0.25.15 release, where RS-SDK was introduced in the project. I believe there were some breaking changes that broke WASM DPP on some specific combination of software and hardware. Check environment for more execution details

Your Environment

Thanks @qwizzie for report, taken from the previous issue

  • Version used: Dash Platform 0.25.15+
  • Environment name and version: Node.JS v20.10.0
  • Operating System: Ubuntu 20.04.6 LTS / GNU/Linux 5.4.0-166-generic x86_64
  • Arch: amd64

CPU:

$lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 44 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz
Stepping: 4
CPU MHz: 2992.972
BogoMIPS: 5985.94
Hypervisor vendor: Microsoft
Virtualization type: full
L1d cache: 256 KiB
L1i cache: 256 KiB
L2 cache: 8 MiB
L3 cache: 198 MiB
NUMA node0 CPU(s): 0-7

pshenmic avatar Dec 08 '23 05:12 pshenmic

We hit this problem again on the production. Previously WASM DPP were included in the dashmate, that caused problem on the @qwizzie system. We then removed dpp from the dashmate that made it work.

Now, with the platform release, @qwizzie hits this problem again, because WASM DPP is used in the DAPI service:

[07:30:50.289] ERROR (34): CompileError: WebAssembly.Module(): Compiling function #1534:"bytecount::simd::wasm::chunk_num_chars::h5a3553..." failed: Wasm SIMD unsupported @+3063056
    at Object.initSync (/platform/packages/wasm-dpp/dist/wasm/wasm_dpp.js:2425:46061)
    at /platform/packages/wasm-dpp/dist/index.js:71:20
    at Generator.next (<anonymous>)
    at /platform/packages/wasm-dpp/dist/index.js:30:71
    at new Promise (<anonymous>)
    at __awaiter (/platform/packages/wasm-dpp/dist/index.js:26:12)
    at loadDppModule (/platform/packages/wasm-dpp/dist/index.js:62:29)
    at /platform/packages/wasm-dpp/dist/index.js:52:30
    at Generator.next (<anonymous>)
    at /platform/packages/wasm-dpp/dist/index.js:30:71

It looks like there is some cross compatibility issue with WASM DPP that is crashing on some CPUs

pshenmic avatar Aug 01 '24 07:08 pshenmic

We did investigate on how we can compile WASM DPP without SIMD requirements but it's very hacky and I'm not sure this is still actual. It was reported only by one user who changed his CPU later to handle it.

shumkov avatar Sep 23 '24 16:09 shumkov