Recognize native TensorFlow crashes with SIGBUS on VMware VM

ℹ️ Support
, ,
1

Support intro

Recognize app crashes with SIGBUS (Bus error, EXIT 135) when running in native TensorFlow mode on a VMware VM. The native libtensorflow binary won’t run; switching to WASM + purejs works as a fallback. Looking to understand the cause and confirm whether the WASM fallback is the right long-term approach, or whether native mode can be made to work in this environment.

The Basics

  • Nextcloud Server version: 33.0.6 Enterprise (33.0.6.3)
  • Recognize app version: 11.0.1
  • Operating system and version: Ubuntu 24.04.4 LTS (kernel 6.8.0-124-generic)
  • Web server and version: Apache 2.4.58 (Ubuntu)
  • Reverse proxy and version: N/A
  • PHP version: 8.3.6 (NTS, OPcache enabled)
  • Is this the first time you’ve seen this error? (Yes / No): Yes
  • When did this problem seem to first start? During initial Recognize setup / first recognize:classify run
  • Installation method: Archive / manual install (from release, directly on the OS) — running on a VMware VM, no Docker/AIO
  • Are you using Cloudflare, mod_security, or similar? (Yes / No): No

Summary of the issue you are facing:

Recognize runs on a VMware-based VM (Intel Xeon Platinum 8558, 8 vCPUs, 16 GiB RAM). In native TensorFlow mode the classifier crashes immediately with a SIGBUS / Bus error (exit code 135). /proc/cpuinfo on the VM shows the hypervisor flag.

Switching tensorflow.mode=wasm alone did not resolve it — the classifier still crashed while native artifacts (tfjs_binding.node, libtensorflow.so symlinks) were present on disk. It started working only after also setting tensorflow.purejs=true. In that configuration, object recognition and face detection both work.

Questions:

  1. What typically causes a SIGBUS from the native libtensorflow binary on a virtualized host — is CPU masking / EVC on the hypervisor a likely cause, and is there a supported way to run native mode in that case (e.g. required CPU flags, host CPU passthrough)?
  2. Why does tensorflow.mode=wasm alone still crash when native artifacts are present on disk, and is tensorflow.purejs=true the intended/recommended way to fully force the WASM path?
  3. Is WASM + purejs a supported long-term configuration, or only a workaround?

Steps to replicate it (hint: details matter!):

  1. Install Recognize on a manual/non-container Nextcloud running on a VMware VM (hypervisor flag present in /proc/cpuinfo).
  2. Download models and run sudo -u www-data php /var/www/nextcloud/occ recognize:classify in default (native) TensorFlow mode.
  3. Process crashes with SIGBUS / Bus error (EXIT 135).
2

Resolved: Recognize native-mode crash (SIGBUS / “Bus error”) — incomplete libtensorflow download

Symptom: Recognize crashes in native mode with Bus error. Direct load gives SIGBUS {si_code=BUS_ADRERR}, exit 135. WASM mode works but is slower.

Cause: Truncated TensorFlow libraries. libtensorflow.so.2.9.1 was 230 MB instead of ~360 MB, and libtensorflow_framework.so was missing. The truncated file’s ELF headers reference data past the end of the file, so touching that mapped region triggers SIGBUS/BUS_ADRERR. One-off bad download during install — not a CPU or hardware issue.

Diagnose: Check the file sizes against a known-good install of the same version:

stat -c '%s' .../tfjs-node/deps/lib/libtensorflow.so.2.9.1

For Recognize 11.0.1 / libtensorflow 2.9.1 (linux x86_64):

  • libtensorflow.so.2.9.1 = 360834960 bytes
  • libtensorflow_framework.so.2.9.1 = 40180768 bytes

Smaller or missing = truncated download.

Fix: Replace both files from the official archive and recreate the symlinks:

# https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-linux-x86_64-2.9.1.tar.gz
chown www-data:www-data libtensorflow*.so.2.9.1
chmod 555 libtensorflow*.so.2.9.1
ln -sf libtensorflow.so.2.9.1 libtensorflow.so.2
ln -sf libtensorflow.so.2 libtensorflow.so
ln -sf libtensorflow_framework.so.2.9.1 libtensorflow_framework.so.2
ln -sf libtensorflow_framework.so.2 libtensorflow_framework.so

Verify:

sudo -u www-data .../recognize/bin/node -e "const tf=require('.../@tensorflow/tfjs-node'); tf.tensor2d([[1,2],[3,4]]).matMul(tf.tensor2d([[1,2],[3,4]])).print(); console.log('OK')"

Prints the matrix + OK = native mode working.

Takeaway: A SIGBUS/BUS_ADRERR on the libtensorflow mmap usually means a truncated library. Check size + checksum before suspecting CPU or hardware.