Description:
mysqlsh reproducibly crashes with SIGSEGV (exit 139) during util.loadDump() restoring a large logical dump (~438GB, ~2.2B rows, 41 tables) from S3-compatible storage. Crash point varies per run (data loading or index building phase) but the signature is always identical. Initially suspected an AVX-512/glibc issue on Cascade Lake and tried disabling AVX-512 via GLIBC_TUNABLES=glibc.cpu.hwcaps=-AVX512F,-AVX512DQ,-AVX512CD,-AVX512BW,-AVX512VL,-AVX512_VNNI — this did not prevent the crash.
Root cause (gdb + core dump): Installed gdb + libc6-dbg, captured a core dump. Crash thread is always in __strlen_evex() with rdi=0x0 (first argument to strlen, per x86-64 calling convention) — i.e. a NULL pointer passed to strlen(), not an AVX-512 hardware bug. Higher stack frames are unresolved (consistent with mysqlsh's embedded GraalVM/JIT engine, libjitexecutor.so); the binary is stripped so the exact JS/native call site couldn't be pinpointed.
How to repeat:
1. util.dumpInstance() to S3-compatible storage.
2. util.loadDump(prefix, {s3BucketName, s3EndpointOverride, s3Region, threads: 4, deferTableIndexes: "all", showProgress: true, showMetadata: true})
3. Against a large dataset, the process eventually crashes with SIGSEGV (139) at a non-deterministic point (observed at 5%, 17%, 58%, 92%, 100%/entering-index-build, mid-index-build).
4. Re-running the identical command (without resetting progress) resumes correctly and eventually completes, sometimes after several crash/resume cycles.
No single small deterministic repro found — crash appears data/timing-dependent, reproduced with both threads=4 and threads=16, with/without deferTableIndexes.
Suggested fix:
Expected: loadDump completes without crashing.
Actual: SIGSEGV (139) at __strlen_evex(), rdi=0x0.
Workaround: progress-file-based resume (load-progress.<server_uuid>.json) reliably continues from the interruption point on re-run — never failed across our testing on either version. Impact is extra wall-clock time only, not data loss.
Attachments available on request: full gdb backtrace + register dump (both versions), dmesg segfault entries. Core dumps (~380MB each) available if needed.
© 2026, Oracle Corporation and/or its affiliates
Description: mysqlsh reproducibly crashes with SIGSEGV (exit 139) during util.loadDump() restoring a large logical dump (~438GB, ~2.2B rows, 41 tables) from S3-compatible storage. Crash point varies per run (data loading or index building phase) but the signature is always identical. Initially suspected an AVX-512/glibc issue on Cascade Lake and tried disabling AVX-512 via GLIBC_TUNABLES=glibc.cpu.hwcaps=-AVX512F,-AVX512DQ,-AVX512CD,-AVX512BW,-AVX512VL,-AVX512_VNNI — this did not prevent the crash. Root cause (gdb + core dump): Installed gdb + libc6-dbg, captured a core dump. Crash thread is always in __strlen_evex() with rdi=0x0 (first argument to strlen, per x86-64 calling convention) — i.e. a NULL pointer passed to strlen(), not an AVX-512 hardware bug. Higher stack frames are unresolved (consistent with mysqlsh's embedded GraalVM/JIT engine, libjitexecutor.so); the binary is stripped so the exact JS/native call site couldn't be pinpointed. How to repeat: 1. util.dumpInstance() to S3-compatible storage. 2. util.loadDump(prefix, {s3BucketName, s3EndpointOverride, s3Region, threads: 4, deferTableIndexes: "all", showProgress: true, showMetadata: true}) 3. Against a large dataset, the process eventually crashes with SIGSEGV (139) at a non-deterministic point (observed at 5%, 17%, 58%, 92%, 100%/entering-index-build, mid-index-build). 4. Re-running the identical command (without resetting progress) resumes correctly and eventually completes, sometimes after several crash/resume cycles. No single small deterministic repro found — crash appears data/timing-dependent, reproduced with both threads=4 and threads=16, with/without deferTableIndexes. Suggested fix: Expected: loadDump completes without crashing. Actual: SIGSEGV (139) at __strlen_evex(), rdi=0x0. Workaround: progress-file-based resume (load-progress.<server_uuid>.json) reliably continues from the interruption point on re-run — never failed across our testing on either version. Impact is extra wall-clock time only, not data loss. Attachments available on request: full gdb backtrace + register dump (both versions), dmesg segfault entries. Core dumps (~380MB each) available if needed.