memory-lancedb-pro can crash OpenClaw Gateway with Illegal Instruction on older non-AVX2 Intel CPU

[mactone]

Summary

memory-lancedb-pro can crash OpenClaw Gateway with Illegal instruction (core dumped) on an older Intel CPU (Celeron J1800, likely non-AVX2). After fixing config/schema mismatches and validating the config successfully, the plugin still caused repeated gateway crashes in the LanceDB native module.

This does not look like a pure config problem anymore. It appears to be a native binary / CPU instruction compatibility problem in @lancedb/lancedb-linux-x64-gnu on older x86_64 hardware.

At the same time, I observed that stable v1.0.32 with a minimal config appears much more stable than v1.1.0-beta.6 on the same host.

---

Environment

• OpenClaw: 2026.3.8
• OS: Linux x86_64
• Node: v22.x
• CPU: Intel Celeron J1800
• Host type: older x86_64 machine, likely non-AVX2
• Plugin repo tested locally from source checkout

Plugin versions tested:

• v1.1.0-beta.6
• v1.0.32

Dependency state observed:

• memory-lancedb-pro@1.1.0-beta.6
• @lancedb/lancedb = ^0.26.2
• local lockfile / installed version resolved to 0.26.2

---

Initial config problems (already solved)

Before reaching the actual crash, I also hit config/schema mismatches. These were corrected and are not the final blocker, but I’m including them because they may help improve docs.

Examples that caused schema validation failures:

• selfImprovement.managementTools

  • current schema does not accept this under selfImprovement
  • the accepted field is top-level enableManagementTools

• memoryReflection.enabled

  • current schema does not accept this field
  • current behavior is controlled via sessionStrategy

After removing those unsupported fields and using a schema-valid config, the gateway still later crashed with Illegal instruction.

So there are really two separate issues:

1. README / example config mismatch with current schema
2. native crash after successful plugin registration on older CPU

---

What happens on v1.1.0-beta.6

With a schema-valid config, the plugin successfully registers:

• memory-lancedb-pro@1.1.0-beta.6: plugin registered
• self-improvement: integrated hooks registered
• session-strategy: using none

The gateway then continues booting, starts providers, and later crashes with core dump.

Observed systemd / journal signals:

• Process ... dumped core
• status=4/ILL
• Failed with result 'core-dump'
• repeated restart loop via systemd

The stack trace repeatedly points to:

/home/.../plugins/memory-lancedb-pro/node_modules/@lancedb/lancedb-linux-x64-gnu/lancedb.linux-x64-gnu.node

Example stack snippet:

#0  0x... n/a (.../lancedb.linux-x64-gnu.node + 0x4b83700)
#1  0x... n/a (.../lancedb.linux-x64-gnu.node + 0x4e4c144)

This happened repeatedly after apparently successful registration / startup.

---

What happens on stable v1.0.32

After checking out v1.0.32 and re-applying a minimal plugin config, I observed a much better result on the same host.

Relevant log lines:

• memory-lancedb-pro@1.0.32: plugin registered (db: ..., model: jina-embeddings-v5-text-small)
• memory-lancedb-pro: initialized successfully (embedding: OK, retrieval: OK, mode: hybrid, FTS: enabled)
• memory-lancedb-pro: backup completed (52 entries -> ...memory-backup-2026-03-12.jsonl)

At least in this test window, stable did not immediately fall into the same crash loop that I saw with beta.

That said, stable v1.0.32 still declares:

• @lancedb/lancedb ^0.26.2

So I’m not yet certain whether the difference comes from:

• a safer execution path in stable,
• different runtime behavior before hitting the problematic native code path,
• or something subtle in plugin feature flow rather than dependency version alone.

---

Why I suspect AVX2 / instruction-set compatibility

The crash mode is highly consistent with known older-CPU incompatibility:

• signal is ILL / illegal instruction
• the failing module is the LanceDB native binary
• this machine is an old Intel Celeron J1800

This also appears consistent with similar upstream reports, for example:

• lance-format/lance#2195
• lancedb/lancedb#592
• lancedb/lancedb#865

In particular, issue discussions around older Intel CPUs point toward AVX2-related incompatibility.

---

Minimal config used for the stable retest

This reduced config was used to minimize variables:

{
  enabled: true,
  config: {
    embedding: {
      provider: 'openai-compatible',
      apiKey: '${JINA_API_KEY}',
      model: 'jina-embeddings-v5-text-small',
      baseURL: 'https://api.jina.ai/v1',
      dimensions: 1024,
      taskQuery: 'retrieval.query',
      taskPassage: 'retrieval.passage',
      normalized: true
    },
    dbPath: '~/.openclaw/memory/lancedb-pro',
    autoCapture: true,
    autoRecall: false,
    retrieval: {
      mode: 'hybrid',
      vectorWeight: 0.7,
      bm25Weight: 0.3,
      minScore: 0.3,
      rerank: 'cross-encoder',
      rerankApiKey: '${JINA_API_KEY}',
      rerankModel: 'jina-reranker-v3',
      rerankProvider: 'jina',
      candidatePoolSize: 20,
      recencyHalfLifeDays: 14,
      recencyWeight: 0.1,
      filterNoise: true,
      lengthNormAnchor: 500,
      hardMinScore: 0.35,
      timeDecayHalfLifeDays: 60,
      reinforcementFactor: 0.5,
      maxHalfLifeMultiplier: 3
    }
  }
}

This config was successfully validated by OpenClaw before restart.

---

Questions

1. Is @lancedb/lancedb 0.26.2 known to require AVX2 (or other newer CPU instructions) on Linux x64 builds?
2. Is there a recommended LanceDB version range for older non-AVX2 Intel CPUs?
3. Is beta v1.1.0-beta.6 known to exercise a code path that is more likely to trigger this native crash than stable v1.0.32?
4. Is there a supported way to build / install LanceDB with more conservative CPU flags for older hardware?
5. Could the README / docs explicitly warn about:
   • schema differences in newer config examples,
   • old Intel / non-AVX2 CPU compatibility,
   • whether stable is safer than beta on older hosts?

---

Suggested documentation improvements

It would help a lot if the repo documented:

• supported CPU instruction assumptions for the prebuilt LanceDB native binary
• whether old x86_64 Intel CPUs (non-AVX2) are expected to work
• whether source build is required on such hosts
• which config fields are current / accepted vs obsolete README examples

---

Practical impact

On this machine, the plugin is not just failing its own features — in beta it can destabilize the entire OpenClaw gateway through repeated core dumps.

That makes CPU compatibility and documentation especially important for users deploying OpenClaw on older low-power x86 boxes.

[AliceLJY]

Thanks for the detailed write-up. At this point this no longer looks like a pure config/schema problem — the status=4/ILL signal plus frames inside @lancedb/lancedb-linux-x64-gnu on a Celeron J1800 line up much more with an upstream native binary / instruction-set compatibility issue.

Your upstream references are directionally consistent with that: there are already older-CPU illegal-instruction reports in lancedb/lancedb#592 and lance-format/lance#2195, plus a docs/hardware-requirements gap in lancedb/lancedb#865.

One important nuance: both the stable and beta cases you tested still resolve @lancedb/lancedb ^0.26.2, so stable looking “more okay” on this host does not yet prove a safe version boundary by itself. My current read is that beta may simply be exercising the problematic native path earlier or more reliably, not necessarily that beta alone introduced the CPU incompatibility.

So for now I would treat older non-AVX2 x86_64 as not guaranteed to work with the prebuilt LanceDB binary unless upstream says otherwise. If you’re willing to add one more data point, the most useful follow-up would be the output of:

lscpu
node -p "process.versions"
npm ls @lancedb/lancedb @lancedb/lancedb-linux-x64-gnu

from the plugin checkout on that machine.

The docs warning request also makes sense. At minimum, we should document the old-Intel / non-AVX2 risk and avoid implying that stable-vs-beta behavior on that hardware is guaranteed.

[mactone]

Thanks — here is the extra environment data from the affected machine.

lscpu

Architecture:                            x86_64
CPU op-mode(s):                          32-bit, 64-bit
Address sizes:                           36 bits physical, 48 bits virtual
Byte Order:                              Little Endian
CPU(s):                                  2
On-line CPU(s) list:                     0,1
Vendor ID:                               GenuineIntel
Model name:                              Intel(R) Celeron(R) CPU  J1800  @ 2.41GHz
CPU family:                              6
Model:                                   55
Thread(s) per core:                      1
Core(s) per socket:                      2
Socket(s):                               1
Stepping:                                8
CPU(s) scaling MHz:                      100%
CPU max MHz:                             2415.7000
CPU min MHz:                             1332.8000
Flags:                                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow flexpriority ept vpid tsc_adjust smep erms dtherm arat vnmi md_clear

Notably, this CPU does not advertise AVX / AVX2.

node -p "process.versions"

{
  "node": "22.22.0",
  "acorn": "8.15.0",
  "ada": "2.9.2",
  "amaro": "1.1.4",
  "ares": "1.34.6",
  "brotli": "1.1.0",
  "cjs_module_lexer": "2.1.0",
  "cldr": "47.0",
  "icu": "77.1",
  "llhttp": "9.3.0",
  "modules": "127",
  "napi": "10",
  "nbytes": "0.1.1",
  "ncrypto": "0.0.1",
  "nghttp2": "1.64.0",
  "openssl": "3.5.4",
  "simdjson": "3.13.0",
  "simdutf": "6.4.2",
  "sqlite": "3.50.4",
  "tz": "2025b",
  "undici": "6.23.0",
  "unicode": "16.0",
  "uv": "1.51.0",
  "uvwasi": "0.0.23",
  "v8": "12.4.254.21-node.33",
  "zlib": "1.3.1-470d3a2",
  "zstd": "1.5.7"
}

Package / dependency check

The installed extension on this machine is:

{
  "name": "@openclaw/memory-lancedb",
  "version": "2026.3.8-beta.1"
}

Running the exact dependency check from the installed extension directory:

cd /home/mactone/.npm-global/lib/node_modules/openclaw/extensions/memory-lancedb
npm ls @lancedb/lancedb @lancedb/lancedb-linux-x64-gnu --depth=3

produced:

@openclaw/memory-lancedb@2026.3.8-beta.1 /home/mactone/.npm-global/lib/node_modules/openclaw/extensions/memory-lancedb
└── (empty)

and running a wider check from the OpenClaw install root also showed empty for those package names:

openclaw@2026.3.8 /home/mactone/.npm-global/lib/node_modules/openclaw
└── (empty)

So on this install, those LanceDB packages are not visible as regular npm deps from the extension / OpenClaw root via npm ls, even though the crash stack previously pointed into the native LanceDB path when the gateway restarted.

If helpful, I can also attach:

1. the exact journalctl crash excerpt again, and/or
2. a minimal reproduction sequence from a fresh OpenClaw install on this same J1800 machine.

[AliceLJY]

Thanks, this is very helpful.

The new lscpu output is the key missing data point: that J1800 does not advertise AVX / AVX2, and upstream Lance has stated that their prebuilt builds target a minimum haswell CPU class (AVX2 + FMA). So at this point I think we can treat this as a confirmed prebuilt-LanceDB CPU compatibility problem on older x86_64, not a remaining config/schema issue.

The empty npm ls result does not really change that read. @lancedb/lancedb distributes platform-specific native binaries such as @lancedb/lancedb-linux-x64-gnu via platform/optional dependencies, and depending on how the OpenClaw extension was installed they may not show up cleanly from the extension root. The stronger signal is still the crash stack landing inside lancedb.linux-x64-gnu.node.

I also do not want to overclaim a safe stable-vs-beta boundary from this one host: both v1.0.32 and v1.1.0-beta.6 still resolve @lancedb/lancedb ^0.26.2. My current read is still that beta is more likely to exercise the problematic native path earlier or more reliably, not necessarily that beta alone introduced a different CPU requirement.

Even if the root cause is upstream, the current plugin behavior is still not acceptable from our side if it can destabilize the whole gateway on unsupported hardware. From the plugin side, the follow-up work for us is:

1. document the older-Intel / non-AVX2 risk clearly
2. avoid implying that stable-vs-beta behavior on that hardware is guaranteed
3. see whether we can fail more gracefully instead of allowing a crash loop when LanceDB is not usable on the host CPU

If you have a minimal fresh-install repro sequence for that J1800 machine, that would still be useful for validating a guard / docs update, but I do not need more environment dumps to accept the core diagnosis.

[NW15D]

Yes, the entire application doesn't work properly on computers without FMA/AVX2 support. LanceDB could be rewritten manually and built from scratch to run on older computers, but it would require a large number of changes. I've already done this and made it work, but installing it would still take 1-2 days of effort either way.

[AliceLJY]

Upstream limitation — LanceDB native binary requires AVX2/FMA instruction sets. Same root cause as #372. If LanceDB provides a fallback build, feel free to reopen.