Skip to content
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

zlib Illegal Instruction on CPU without SSSE3/SSE4.2 support #7688

Open
Cubelrti opened this issue Mar 1, 2021 · 4 comments
Open

zlib Illegal Instruction on CPU without SSSE3/SSE4.2 support #7688

Cubelrti opened this issue Mar 1, 2021 · 4 comments
Labels

Comments

@Cubelrti
Copy link
Contributor

Cubelrti commented Mar 1, 2021

I am experiencing the same bug as nodejs/node#32553 mentioned.

NWJS Version : 0.49.0
Operating System : Windows 7 SP1 6.1.7601 24520

Expected behavior

zlib.gzipSync(data) should work with any CPU.

Actual behavior

When calling zlib.gzipSync(data) in 0.49.0 with some CPU architecture, the webview crashed with EXCEPTION_ILLEGAL_INSTRUCTION.

Experiencing this issue in the following CPUs:

  • Intel Pentium E6700
  • AMD Athlon X4 631

Those two CPUs don't have SSSE3/SSE4.2 supported, which might be the issue.

How to reproduce

Operating system: Windows NT
                  6.1.7601 24520
CPU: amd64
     family 6 model 23 stepping 10
     2 CPUs

GPU: UNKNOWN

Crash reason:  EXCEPTION_ILLEGAL_INSTRUCTION
Crash address: 0x7feec7335f5
Process uptime: 216 seconds

Thread 0 (crashed)
 0  node.dll!fill_window [deflate.c : 1527 + 0x10d]
    rax = 0x0000000000008000   rdx = 0x0000000000000000
    rcx = 0x0000000016735228   rbx = 0xffffffffffff8000
    rsi = 0x00000000166e7e98   rdi = 0x0000000016745218
    rbp = 0x0000000000000000   rsp = 0x000000000097c560
     r8 = 0x0000000000008000    r9 = 0x0000000000008000
    r10 = 0x00000000166f1618   r11 = 0x00000000166e9618
    r12 = 0x0000000000008000   r13 = 0x0000000000000000
    r14 = 0x0000000000000004   r15 = 0x0000000000000000
    rip = 0x000007feec7335f5
    Found by: given as instruction pointer in context
 1  node.dll!deflate_slow [deflate.c : 1989 + 0x8]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097c600   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007feec73668f
    Found by: call frame info
 2  node.dll!deflate [deflate.c : 1037 + 0x38]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097c670   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007feec734be0
    Found by: call frame info
 3  node.dll!node::`anonymous namespace'::CompressionStream<node::(anonymous namespace)::ZlibContext>::DoThreadPoolWork [node_zlib.cc : 380 + 0xdc]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097c6e0   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007feec6b0758
    Found by: call frame info
 4  node.dll!node::`anonymous namespace'::CompressionStream<node::(anonymous namespace)::ZlibContext>::Write<0> [node_zlib.cc : 335 + 0xa2]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097c750   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007feec6af976
    Found by: call frame info
 5  nw.dll!v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [api-arguments-inl.h : 158 + 0x6]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097c7d0   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007fecd3b6bab
    Found by: call frame info
 6  nw.dll!v8::internal::`anonymous namespace'::HandleApiCallHelper<0> [builtins-api.cc : 111 + 0xb]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097c900   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007fecd3b6038
    Found by: call frame info
 7  nw.dll!v8::internal::Builtin_Impl_HandleApiCall [builtins-api.cc : 141 + 0x2d]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097ca10   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007fecd3b54f8
    Found by: call frame info
 8  nw.dll!v8::internal::Builtin_HandleApiCall(int,unsigned __int64 *,v8::internal::Isolate *) [builtins-api.cc : 129 + 0x1c]
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097cae0   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007fecd3b5107
    Found by: call frame info
 9  nw.dll!Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 0x3c
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097cb40   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000007fecddaebdc
    Found by: call frame info
10  0x97cbd0
    rbx = 0xffffffffffff8000   rbp = 0x0000000000000000
    rsp = 0x000000000097cb50   r12 = 0x0000000000008000
    r13 = 0x0000000000000000   r14 = 0x0000000000000004
    r15 = 0x0000000000000000   rip = 0x000000000097cbd0
    Found by: call frame info
11  nw.dll!Builtins_InterpreterEntryTrampoline + 0xd5
    rsp = 0x000000000097cb98   rip = 0x000007fecdd42a15
    Found by: stack scanning
12  0x5410bb7af55
    rsp = 0x000000000097cba8   rip = 0x000005410bb7af55
    Found by: call frame info

Also

I tried to remove flags in zlib.gyp which is also removed by upstream node here, but I cannot compile node after removing -msse4.2 (removing -mssse3 is fine).

I think it relates to nodejs/node@65db9b2 this change, but 0.49.0 already has this patch in it.

@ayushmanchhabra
Copy link
Contributor

Does it still happen on the latest version?

@Cubelrti
Copy link
Contributor Author

Yes it happens since 0.49.0, but we manually disabled SSSE3 features by the following patch:

diff --git a/deps/zlib/crc32.c b/deps/zlib/crc32.c
index e95b9087351c1a46dda520025c55d0ef8a1484e0..7db41a794a97beeb556370bd6778894998539fe7 100644
--- a/deps/zlib/crc32.c
+++ b/deps/zlib/crc32.c
@@ -501,7 +501,7 @@ uLong ZEXPORT crc32_combine64(crc1, crc2, len2)
 ZLIB_INTERNAL void crc_reset(deflate_state *const s)
 {
     if (x86_cpu_enable_simd) {
-        crc_fold_init(s);
+        // crc_fold_init(s);
         return;
     }
     s->strm->adler = crc32(0L, Z_NULL, 0);
@@ -509,14 +509,14 @@ ZLIB_INTERNAL void crc_reset(deflate_state *const s)
 
 ZLIB_INTERNAL void crc_finalize(deflate_state *const s)
 {
-    if (x86_cpu_enable_simd)
-        s->strm->adler = crc_fold_512to32(s);
+    // if (x86_cpu_enable_simd)
+        // s->strm->adler = crc_fold_512to32(s);
 }
 
 ZLIB_INTERNAL void copy_with_crc(z_streamp strm, Bytef *dst, long size)
 {
     if (x86_cpu_enable_simd) {
-        crc_fold_copy(strm->state, dst, strm->next_in, size);
+        // crc_fold_copy(strm->state, dst, strm->next_in, size);
         return;
     }
     zmemcpy(dst, strm->next_in, size);

@ayushmanchhabra
Copy link
Contributor

ayushmanchhabra commented Oct 22, 2022

I'm gonna be honest I am waaay out of my depth here. I'll leave this open for anyone who encounters this error

@BoryaGames
Copy link

Got same problem with "unzipper", it unzipped zero/one file and crashes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants