https://gitlab.synchro.net/main/sbbs/-/issues/685#note_7994

I know this is an old thread, but from what I can see it remains an issue. I've traced through the core dump I am receiving on ARM64 and it seems to be a known issue on ARM64 with SpyderMonkey 1.8.5.

* I made sure it was building from the included 3rd party source. Are there patches than need to be applied to that for ARM64?

* Are there any plans to upgrade to a newer version of SpyderMonkey where this issue has been fixed?

I see some boards listed as running ARM64 - just wondering how they do it?
--- SBBSecho 3.33-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_7997

The patches that need to be applied are automatically applied by the build system. Without seeing at least the backtrace, and possibly the `ldd` output, we can't theorize what exactly is happening.

The only arm64 platforms that are generally tested at all are macOS and Linux. --- SBBSecho 3.33-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_7998

Deuce, thanks for the reply. I have it working on x86_64 on Linux, but would love to get it working native Arm. I've tried on both MacOS and Linux with same seg fault result. I also looked at upgrading SpyderMonkey to a newer version, but the API has changed significantly and I think would unfortunately require quite a bit of re-wiring.

I've included a test Dockerfile (Debian 22) that reproduces it and captures the crash with LDD.

Synchronet ARM64 SpiderMonkey 1.8.5 Debug Report
Date: December 26, 2025
Platform: Debian Bookworm (aarch64/ARM64)
Build: Docker container, debian:bookworm-slim base

1. LDD Output
SpiderMonkey is statically linked into libsbbs.so, so no separate libmozjs*.so appears:
```
linux-vdso.so.1 (0x0000ffff85c02000)
libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2
libsbbs.so => /sbbs/exec/libsbbs.so ← Contains static mozjs libftpsrvr.so => /sbbs/exec/libftpsrvr.so
libwebsrvr.so => /sbbs/exec/libwebsrvr.so
libmailsrvr.so => /sbbs/exec/libmailsrvr.so
libservices.so => /sbbs/exec/libservices.so
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6
/lib/ld-linux-aarch64.so.1
libnspr4.so => /lib/aarch64-linux-gnu/libnspr4.so
libarchive.so.13 => /lib/aarch64-linux-gnu/libarchive.so.13
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1
libnettle.so.8 => /lib/aarch64-linux-gnu/libnettle.so.8
[... additional system libs ...]
```
Confirmation: No system mozjs packages installed. The static libmozjs185-1.0.a from the Synchronet 3rdp build is linked into libsbbs.so.

2. Build Configuration (from build.log)
SpiderMonkey configure flags:
```
./configure \
--with-system-nspr \
--disable-tests \
--disable-shared-js \ ← Static library
--enable-threadsafe \
--enable-ctypes \
--enable-optimize=-O3 \
--build=aarch64-linux-gnu \
--host=aarch64-linux-gnu \
--target=aarch64-linux-gnu
Final static library created:
libmozjs185-1.0.a
Linked into libsbbs.so:
g++ ... -o libsbbs.so ... /sbbs/src/sbbs3/../../3rdp/gcc.linux.aarch64.release/mozjs/lib/libmozjs185-1.0.a ...
```

3. Patches Applied (confirmed in build.log)
All patches were successfully applied during build:
```
patch -b -p0 -d .../mozjs/js-1.8.5 < js_src_jsnativestack_cpp.patch
patch -b -p0 -d .../mozjs < js-configure.patch
patch -b -p0 -d .../mozjs < js-configure.in.patch
patch -b -p0 -d .../mozjs < imacro-asm-fix.patch
patch -b -p0 -d .../mozjs < js-volatile-outside-functions.patch
patch -b -p0 -d .../mozjs < js-Wno-misleading-indentation.patch
patch -b -p0 -d .../mozjs < js-allow-python3.patch
patch -b -p0 -d .../mozjs < js-config.guess.patch
patch -b -p0 -d .../mozjs < js-makefile.patch
patch -b -p0 -d .../mozjs < js-disable-warnings.patch
patch -b -p0 -d .../mozjs < js-disable-shell.patch
patch -b -p0 -d .../mozjs < js-no-rwx-pages.patch
patch -b -p0 -d .../mozjs < js-darwin-configure.patch
patch -b -p0 -d .../mozjs < js-keep-ffi-cache.patch
patch -b -p0 -d .../mozjs < js-support-mingw-cross.patch
patch -b -p0 -d .../mozjs < js-int-main-conf.patch
patch -b -p0 -d .../mozjs < js-include-headers.patch
patch -b -p0 -d .../mozjs < js-macos-configure.patch
patch -b -p0 -d .../mozjs < js-isfinite.patch
patch -b -p0 -d .../mozjs < js-libffi-prefix.patch
patch -b -p0 -d .../mozjs < js-map-aligned.patch
```
No patch failures reported in the build output.

4. GDB Backtrace

```
Thread 12 "sbbs/events" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xffff70c0f180 (LWP 613)]
0x0000ffff7e70a250 in js_GetClassPrototype(JSContext*, JSObject*, JSProtoKey, JSObject**, js::Class*) ()
from /sbbs/exec/libsbbs.so

=== Backtrace ===
#0 0x0000ffff7e70a250 in js_GetClassPrototype(JSContext*, JSObject*, JSProtoKey, JSObject**, js::Class*) ()
from /sbbs/exec/libsbbs.so
#1 0x0000ffff7e6d45d4 in js_NewFunction(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#2 0x0000ffff7e6d6e14 in js_DefineFunction(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#3 0x0000ffff7e684d4c in JS_DefineFunctions ()
from /sbbs/exec/libsbbs.so
#4 0x0000ffff7e70c980 in js::DefineConstructorAndPrototype(JSContext*, JSObject*, JSProtoKey, ...) ()
from /sbbs/exec/libsbbs.so
#5 0x0000ffff7e70d5b0 in js_InitClass(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#6 0x0000ffff7e6d4c5c in js_InitFunctionClass(JSContext*, JSObject*) ()
from /sbbs/exec/libsbbs.so
#7 0x0000ffff7e684b18 in js_InitFunctionAndObjectClasses(JSContext*, JSObject*) ()
from /sbbs/exec/libsbbs.so
#8 0x0000ffff7e684bb8 in JS_InitStandardClasses ()
from /sbbs/exec/libsbbs.so
#9 0x0000ffff7e58f710 in js_CreateGlobalObject ()
from /sbbs/exec/libsbbs.so
#10 0x0000ffff7e5e8884 in js_CreateCommonObjects ()
from /sbbs/exec/libsbbs.so
#11 0x0000ffff7e5e8bd4 in sbbs_t::js_init(JSRuntime**, JSObject**, char const*) ()
from /sbbs/exec/libsbbs.so
#12 0x0000ffff7e5f2988 in event_thread(void*) [clone .part.0] ()
from /sbbs/exec/libsbbs.so
#13 0x0000ffff7e1e2030 in start_thread (arg=0x0) at ./nptl/pthread_create.c:442 #14 0x0000ffff7e24bf1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
```
The crash occurs during JavaScript runtime initialization, specifically when js_InitFunctionClass() calls js_GetClassPrototype(). This happens in the "sbbs/events" thread before any user scripts run.

5. System Information

```
Architecture: aarch64 (ARM64)
OS: Debian GNU/Linux 12 (bookworm)
Kernel: Linux (Docker container)
Binary type: ELF 64-bit LSB pie executable, ARM aarch64
```

6. Memory Map (relevant sections)
```
0xffff7e400000 - 0xffff7ea23000 r-xp /sbbs/exec/libsbbs.so (6.1MB code) 0xffff7ea39000 - 0xffff7ea80000 r--p /sbbs/exec/libsbbs.so (data) 0xffff7ea80000 - 0xffff7eaa2000 rw-p /sbbs/exec/libsbbs.so (writable)
```
The crash address 0x0000ffff7e70a250 is within the executable code section of libsbbs.so.

7. Questions for Further Investigation

* Are there any ARM64/aarch64-specific patches that should be applied but aren't in the current patch set?
* Is there a known issue with js_GetClassPrototype() on ARM64 with this version of SpiderMonkey?
* The build uses `--with-system-nspr` — could there be an incompatibility between system NSPR (from Debian) and the SpiderMonkey build on ARM64?
* libffi is also built from source for ctypes support:
```
src/aarch64/ffi.o src/aarch64/sysv.o
```
Could there be an issue with the libffi ARM64 calling conventions?

Files Attached

* ldd-sbbs.txt - Full LDD output
* gdb-backtrace.txt - Complete GDB session with all thread backtraces
* build.log - Full build output (grep for "patch" to see patch application)

[build.log](/uploads/c280d8dd0279934a90058aa19f1e69a2/build.log)

[gdb-backtrace.txt](/uploads/8c30c259e1c19ac91cb918c434153284/gdb-backtrace.txt)

[ldd-sbbs.txt](/uploads/acaea3982a92d9ffd2ac2c9d0685c48c/ldd-sbbs.txt)

[Dockerfile.arm64-debug](/uploads/63f0746fc6530b075aa28bc336e0bfae/Dockerfile.arm64-debug))
--- SBBSecho 3.33-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_7998

Deuce, thanks for the reply. I have it working on x86_64 on Linux, but would love to get it working native Arm. I've tried on both MacOS and Linux with same seg fault result. I also looked at upgrading SpyderMonkey to a newer version, but the API has changed significantly and I think would unfortunately require quite a bit of re-wiring.

I've included a test Dockerfile (Debian 22) that reproduces it and captures the crash with LDD.

Synchronet ARM64 SpiderMonkey 1.8.5 Debug Report
Date: December 26, 2025
Platform: Debian Bookworm (aarch64/ARM64)
Build: Docker container, debian:bookworm-slim base

1. LDD Output
SpiderMonkey is statically linked into libsbbs.so, so no separate libmozjs*.so appears:
```
linux-vdso.so.1 (0x0000ffff85c02000)
libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2
libsbbs.so => /sbbs/exec/libsbbs.so ← Contains static mozjs libftpsrvr.so => /sbbs/exec/libftpsrvr.so
libwebsrvr.so => /sbbs/exec/libwebsrvr.so
libmailsrvr.so => /sbbs/exec/libmailsrvr.so
libservices.so => /sbbs/exec/libservices.so
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6
/lib/ld-linux-aarch64.so.1
libnspr4.so => /lib/aarch64-linux-gnu/libnspr4.so
libarchive.so.13 => /lib/aarch64-linux-gnu/libarchive.so.13
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1
libnettle.so.8 => /lib/aarch64-linux-gnu/libnettle.so.8
[... additional system libs ...]
```
Confirmation: No system mozjs packages installed. The static libmozjs185-1.0.a from the Synchronet 3rdp build is linked into libsbbs.so.

2. Build Configuration (from build.log)
SpiderMonkey configure flags:
```
./configure \
--with-system-nspr \
--disable-tests \
--disable-shared-js \ ← Static library
--enable-threadsafe \
--enable-ctypes \
--enable-optimize=-O3 \
--build=aarch64-linux-gnu \
--host=aarch64-linux-gnu \
--target=aarch64-linux-gnu
Final static library created:
libmozjs185-1.0.a
Linked into libsbbs.so:
g++ ... -o libsbbs.so ... /sbbs/src/sbbs3/../../3rdp/gcc.linux.aarch64.release/mozjs/lib/libmozjs185-1.0.a ...
```

3. Patches Applied (confirmed in build.log)
All patches were successfully applied during build:
```
patch -b -p0 -d .../mozjs/js-1.8.5 < js_src_jsnativestack_cpp.patch
patch -b -p0 -d .../mozjs < js-configure.patch
patch -b -p0 -d .../mozjs < js-configure.in.patch
patch -b -p0 -d .../mozjs < imacro-asm-fix.patch
patch -b -p0 -d .../mozjs < js-volatile-outside-functions.patch
patch -b -p0 -d .../mozjs < js-Wno-misleading-indentation.patch
patch -b -p0 -d .../mozjs < js-allow-python3.patch
patch -b -p0 -d .../mozjs < js-config.guess.patch
patch -b -p0 -d .../mozjs < js-makefile.patch
patch -b -p0 -d .../mozjs < js-disable-warnings.patch
patch -b -p0 -d .../mozjs < js-disable-shell.patch
patch -b -p0 -d .../mozjs < js-no-rwx-pages.patch
patch -b -p0 -d .../mozjs < js-darwin-configure.patch
patch -b -p0 -d .../mozjs < js-keep-ffi-cache.patch
patch -b -p0 -d .../mozjs < js-support-mingw-cross.patch
patch -b -p0 -d .../mozjs < js-int-main-conf.patch
patch -b -p0 -d .../mozjs < js-include-headers.patch
patch -b -p0 -d .../mozjs < js-macos-configure.patch
patch -b -p0 -d .../mozjs < js-isfinite.patch
patch -b -p0 -d .../mozjs < js-libffi-prefix.patch
patch -b -p0 -d .../mozjs < js-map-aligned.patch
```
No patch failures reported in the build output.

4. GDB Backtrace

```
Thread 12 "sbbs/events" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xffff70c0f180 (LWP 613)]
0x0000ffff7e70a250 in js_GetClassPrototype(JSContext*, JSObject*, JSProtoKey, JSObject**, js::Class*) ()
from /sbbs/exec/libsbbs.so

=== Backtrace ===
#0 0x0000ffff7e70a250 in js_GetClassPrototype(JSContext*, JSObject*, JSProtoKey, JSObject**, js::Class*) ()
from /sbbs/exec/libsbbs.so
#1 0x0000ffff7e6d45d4 in js_NewFunction(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#2 0x0000ffff7e6d6e14 in js_DefineFunction(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#3 0x0000ffff7e684d4c in JS_DefineFunctions ()
from /sbbs/exec/libsbbs.so
#4 0x0000ffff7e70c980 in js::DefineConstructorAndPrototype(JSContext*, JSObject*, JSProtoKey, ...) ()
from /sbbs/exec/libsbbs.so
#5 0x0000ffff7e70d5b0 in js_InitClass(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#6 0x0000ffff7e6d4c5c in js_InitFunctionClass(JSContext*, JSObject*) ()
from /sbbs/exec/libsbbs.so
#7 0x0000ffff7e684b18 in js_InitFunctionAndObjectClasses(JSContext*, JSObject*) ()
from /sbbs/exec/libsbbs.so
#8 0x0000ffff7e684bb8 in JS_InitStandardClasses ()
from /sbbs/exec/libsbbs.so
#9 0x0000ffff7e58f710 in js_CreateGlobalObject ()
from /sbbs/exec/libsbbs.so
#10 0x0000ffff7e5e8884 in js_CreateCommonObjects ()
from /sbbs/exec/libsbbs.so
#11 0x0000ffff7e5e8bd4 in sbbs_t::js_init(JSRuntime**, JSObject**, char const*) ()
from /sbbs/exec/libsbbs.so
#12 0x0000ffff7e5f2988 in event_thread(void*) [clone .part.0] ()
from /sbbs/exec/libsbbs.so
#13 0x0000ffff7e1e2030 in start_thread (arg=0x0) at ./nptl/pthread_create.c:442 #14 0x0000ffff7e24bf1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
```
The crash occurs during JavaScript runtime initialization, specifically when js_InitFunctionClass() calls js_GetClassPrototype(). This happens in the "sbbs/events" thread before any user scripts run.

5. System Information

```
Architecture: aarch64 (ARM64)
OS: Debian GNU/Linux 12 (bookworm)
Kernel: Linux (Docker container)
Binary type: ELF 64-bit LSB pie executable, ARM aarch64
```

6. Memory Map (relevant sections)
```
0xffff7e400000 - 0xffff7ea23000 r-xp /sbbs/exec/libsbbs.so (6.1MB code) 0xffff7ea39000 - 0xffff7ea80000 r--p /sbbs/exec/libsbbs.so (data) 0xffff7ea80000 - 0xffff7eaa2000 rw-p /sbbs/exec/libsbbs.so (writable)
```
The crash address 0x0000ffff7e70a250 is within the executable code section of libsbbs.so.

7. Questions for Further Investigation

* Are there any ARM64/aarch64-specific patches that should be applied but aren't in the current patch set?
* Is there a known issue with js_GetClassPrototype() on ARM64 with this version of SpiderMonkey?
* The build uses `--with-system-nspr` — could there be an incompatibility between system NSPR (from Debian) and the SpiderMonkey build on ARM64?
* libffi is also built from source for ctypes support:
```
src/aarch64/ffi.o src/aarch64/sysv.o
```
Could there be an issue with the libffi ARM64 calling conventions?

Files Attached

* ldd-sbbs.txt - Full LDD output
* gdb-backtrace.txt - Complete GDB session with all thread backtraces
* build.log - Full build output (grep for "patch" to see patch application)

[build.log](/uploads/c280d8dd0279934a90058aa19f1e69a2/build.log)

[gdb-backtrace.txt](/uploads/8c30c259e1c19ac91cb918c434153284/gdb-backtrace.txt)

[ldd-sbbs.txt](/uploads/acaea3982a92d9ffd2ac2c9d0685c48c/ldd-sbbs.txt)

[Dockerfile.arm64-debug](/uploads/63f0746fc6530b075aa28bc336e0bfae/Dockerfile.arm64-debug)
--- SBBSecho 3.33-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_7998

Deuce, thanks for the reply. I have it working on x86_64 on Linux, but would love to get it working native Arm. I've tried on both MacOS and Linux with same seg fault result. I also looked at upgrading SpyderMonkey to a newer version, but the API has changed significantly and I think would unfortunately require quite a bit of re-wiring.

I've included a test Dockerfile (Debian 22) that reproduces it and captures the crash with LDD.

* Synchronet ARM64 SpiderMonkey 1.8.5 Debug Report
* Date: December 26, 2025
* Platform: Debian Bookworm (aarch64/ARM64)
* Build: Docker container, debian:bookworm-slim base

1. LDD Output
SpiderMonkey is statically linked into libsbbs.so, so no separate libmozjs*.so appears:
```
linux-vdso.so.1 (0x0000ffff85c02000)
libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2
libsbbs.so => /sbbs/exec/libsbbs.so ← Contains static mozjs libftpsrvr.so => /sbbs/exec/libftpsrvr.so
libwebsrvr.so => /sbbs/exec/libwebsrvr.so
libmailsrvr.so => /sbbs/exec/libmailsrvr.so
libservices.so => /sbbs/exec/libservices.so
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6
/lib/ld-linux-aarch64.so.1
libnspr4.so => /lib/aarch64-linux-gnu/libnspr4.so
libarchive.so.13 => /lib/aarch64-linux-gnu/libarchive.so.13
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1
libnettle.so.8 => /lib/aarch64-linux-gnu/libnettle.so.8
[... additional system libs ...]
```
Confirmation: No system mozjs packages installed. The static libmozjs185-1.0.a from the Synchronet 3rdp build is linked into libsbbs.so.

2. Build Configuration (from build.log)
SpiderMonkey configure flags:
```
./configure \
--with-system-nspr \
--disable-tests \
--disable-shared-js \ ← Static library
--enable-threadsafe \
--enable-ctypes \
--enable-optimize=-O3 \
--build=aarch64-linux-gnu \
--host=aarch64-linux-gnu \
--target=aarch64-linux-gnu
Final static library created:
libmozjs185-1.0.a
Linked into libsbbs.so:
g++ ... -o libsbbs.so ... /sbbs/src/sbbs3/../../3rdp/gcc.linux.aarch64.release/mozjs/lib/libmozjs185-1.0.a ...
```

3. Patches Applied (confirmed in build.log)
All patches were successfully applied during build:
```
patch -b -p0 -d .../mozjs/js-1.8.5 < js_src_jsnativestack_cpp.patch
patch -b -p0 -d .../mozjs < js-configure.patch
patch -b -p0 -d .../mozjs < js-configure.in.patch
patch -b -p0 -d .../mozjs < imacro-asm-fix.patch
patch -b -p0 -d .../mozjs < js-volatile-outside-functions.patch
patch -b -p0 -d .../mozjs < js-Wno-misleading-indentation.patch
patch -b -p0 -d .../mozjs < js-allow-python3.patch
patch -b -p0 -d .../mozjs < js-config.guess.patch
patch -b -p0 -d .../mozjs < js-makefile.patch
patch -b -p0 -d .../mozjs < js-disable-warnings.patch
patch -b -p0 -d .../mozjs < js-disable-shell.patch
patch -b -p0 -d .../mozjs < js-no-rwx-pages.patch
patch -b -p0 -d .../mozjs < js-darwin-configure.patch
patch -b -p0 -d .../mozjs < js-keep-ffi-cache.patch
patch -b -p0 -d .../mozjs < js-support-mingw-cross.patch
patch -b -p0 -d .../mozjs < js-int-main-conf.patch
patch -b -p0 -d .../mozjs < js-include-headers.patch
patch -b -p0 -d .../mozjs < js-macos-configure.patch
patch -b -p0 -d .../mozjs < js-isfinite.patch
patch -b -p0 -d .../mozjs < js-libffi-prefix.patch
patch -b -p0 -d .../mozjs < js-map-aligned.patch
```
No patch failures reported in the build output.

4. GDB Backtrace

```
Thread 12 "sbbs/events" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xffff70c0f180 (LWP 613)]
0x0000ffff7e70a250 in js_GetClassPrototype(JSContext*, JSObject*, JSProtoKey, JSObject**, js::Class*) ()
from /sbbs/exec/libsbbs.so

=== Backtrace ===
#0 0x0000ffff7e70a250 in js_GetClassPrototype(JSContext*, JSObject*, JSProtoKey, JSObject**, js::Class*) ()
from /sbbs/exec/libsbbs.so
#1 0x0000ffff7e6d45d4 in js_NewFunction(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#2 0x0000ffff7e6d6e14 in js_DefineFunction(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#3 0x0000ffff7e684d4c in JS_DefineFunctions ()
from /sbbs/exec/libsbbs.so
#4 0x0000ffff7e70c980 in js::DefineConstructorAndPrototype(JSContext*, JSObject*, JSProtoKey, ...) ()
from /sbbs/exec/libsbbs.so
#5 0x0000ffff7e70d5b0 in js_InitClass(JSContext*, JSObject*, ...) ()
from /sbbs/exec/libsbbs.so
#6 0x0000ffff7e6d4c5c in js_InitFunctionClass(JSContext*, JSObject*) ()
from /sbbs/exec/libsbbs.so
#7 0x0000ffff7e684b18 in js_InitFunctionAndObjectClasses(JSContext*, JSObject*) ()
from /sbbs/exec/libsbbs.so
#8 0x0000ffff7e684bb8 in JS_InitStandardClasses ()
from /sbbs/exec/libsbbs.so
#9 0x0000ffff7e58f710 in js_CreateGlobalObject ()
from /sbbs/exec/libsbbs.so
#10 0x0000ffff7e5e8884 in js_CreateCommonObjects ()
from /sbbs/exec/libsbbs.so
#11 0x0000ffff7e5e8bd4 in sbbs_t::js_init(JSRuntime**, JSObject**, char const*) ()
from /sbbs/exec/libsbbs.so
#12 0x0000ffff7e5f2988 in event_thread(void*) [clone .part.0] ()
from /sbbs/exec/libsbbs.so
#13 0x0000ffff7e1e2030 in start_thread (arg=0x0) at ./nptl/pthread_create.c:442 #14 0x0000ffff7e24bf1c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
```
The crash occurs during JavaScript runtime initialization, specifically when js_InitFunctionClass() calls js_GetClassPrototype(). This happens in the "sbbs/events" thread before any user scripts run.

5. System Information

```
Architecture: aarch64 (ARM64)
OS: Debian GNU/Linux 12 (bookworm)
Kernel: Linux (Docker container)
Binary type: ELF 64-bit LSB pie executable, ARM aarch64
```

6. Memory Map (relevant sections)
```
0xffff7e400000 - 0xffff7ea23000 r-xp /sbbs/exec/libsbbs.so (6.1MB code) 0xffff7ea39000 - 0xffff7ea80000 r--p /sbbs/exec/libsbbs.so (data) 0xffff7ea80000 - 0xffff7eaa2000 rw-p /sbbs/exec/libsbbs.so (writable)
```
The crash address 0x0000ffff7e70a250 is within the executable code section of libsbbs.so.

7. Questions for Further Investigation

* Are there any ARM64/aarch64-specific patches that should be applied but aren't in the current patch set?
* Is there a known issue with js_GetClassPrototype() on ARM64 with this version of SpiderMonkey?
* The build uses `--with-system-nspr` — could there be an incompatibility between system NSPR (from Debian) and the SpiderMonkey build on ARM64?
* libffi is also built from source for ctypes support:
```
src/aarch64/ffi.o src/aarch64/sysv.o
```
Could there be an issue with the libffi ARM64 calling conventions?

Files Attached

* ldd-sbbs.txt - Full LDD output
* gdb-backtrace.txt - Complete GDB session with all thread backtraces
* build.log - Full build output (grep for "patch" to see patch application)

[build.log](/uploads/c280d8dd0279934a90058aa19f1e69a2/build.log)

[gdb-backtrace.txt](/uploads/8c30c259e1c19ac91cb918c434153284/gdb-backtrace.txt)

[ldd-sbbs.txt](/uploads/acaea3982a92d9ffd2ac2c9d0685c48c/ldd-sbbs.txt)

[Dockerfile.arm64-debug](/uploads/63f0746fc6530b075aa28bc336e0bfae/Dockerfile.arm64-debug)
--- SBBSecho 3.33-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs binary: Debian Linux AARCH64 sigfault or permission denied
By: Jonathan Gould to GitLab note in main/sbbs on Fri Dec 26 2025 05:00 am

Hey Jonathan,

Deuce, thanks for the reply. I have it working on x86_64 on Linux, but would love to get it working native Arm. I've tried on both MacOS and Linux with same seg fault result.

I've included a test Dockerfile (Debian 22) that reproduces it and captures the crash with LDD.

I've been running Synchronet on aarch64 - a CM5 for a long time, in docker as well...

My build is here if it helps you:
https://gitea.dege.au/bbs/sbbs/


...����

---
� Synchronet � AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs binary: Debian Linux AARCH64 sigfault or permission denied
By: Jonathan Gould to GitLab note in main/sbbs on Fri Dec 26 2025 04:53 am

Analysis: The crash occurs during JavaScript runtime initialization, specifically when js_InitFunctionClass() calls js_GetClassPrototype(). This happens in the "sbbs/events" thread before any user scripts run.

What if you disable the events thread (by setting NO_EVENTS in the [bbs] Options value of your ctrl/sbbs.ini file) - does the crash still happen, but just somewhere else?
--
digital man (rob)

Sling Blade quote #5:
Karl Childers (to father): You ought not killed my little brother...
Norco, CA WX: 54.6�F, 85.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8025

Correct - running with no events resolves the seg fault.
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8025

Correct - running with no events resolves the seg fault on startup. I imagine eventually you can trigger it when running another js function
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8027

Oh, also, please remove `RELEASE=1` from your build to build a debug version, it makes the backtraces a lot more helpful.

I just double-checked on my RPi 500, and it seems to build and run for me there. :disappointed:
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8028

One thing I notice is that the .so paths in ldd output are in the exec directory (ie: `libftpsrvr.so => /sbbs/exec/libftpsrvr.so`). Can you ensure these are copied correctly? On my systems, these are in the build output directory (ie: `/sbbs/src/sbbs3/gcc.linux.aarch64.lib.workbench/libsbbs.so`)
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8067

@Deuce here's an update from my further debugging...

# Synchronet ARM64 Crash Report - SpiderMonkey js_GetClassPrototype Segfault

## Summary
Synchronet BBS crashes with a segmentation fault on ARM64 (aarch64) when JavaScript initializes during the events thread startup. The crash occurs in `js_GetClassPrototype()` within SpiderMonkey.

## ROOT CAUSE IDENTIFIED: 47-bit Pointer Limitation in SpiderMonkey NaN-boxing

**The crash is caused by SpiderMonkey 1.8.5's NaN-boxing scheme only supporting 47-bit pointers, but ARM64 Linux allocates memory at addresses requiring 48+ bits.**

### Evidence from GDB:

```
(gdb) print /x 0xffffd2c04100 >> 47
$2 = 0x1
```

The address `0xffffd2c04100` has bit 47 set. When SpiderMonkey masks it to 47 bits:
- Original: `0xffffd2c04100`
- After 47-bit mask: `0x7fffd2c04100` (WRONG - high bit lost!)

Register dump showing the problem:
```
x0 0x7fffd2c04100 (invalid - masked to 47 bits)
x1 0xfffbffffd2c04100 (NaN-boxed value containing original pointer)
```

## SOLUTION FOUND

**Run sbbs with `setarch --addr-compat-layout` to force memory allocations into the lower 47-bit address space:**

```bash
setarch $(uname -m) --addr-compat-layout /sbbs/exec/sbbs
```

This works because `--addr-compat-layout` tells the kernel to use the legacy memory layout which keeps allocations in the lower address range where SpiderMonkey's 47-bit pointers work correctly.

### For Docker deployment, update the entrypoint:

```bash
#!/bin/bash
exec setarch $(uname -m) --addr-compat-layout /sbbs/exec/sbbs "$@"
```

## Environment

**System:**
- OS: Kali GNU/Linux Rolling 2025.2
- Kernel: 6.12.33+kali-arm64 #1 SMP
- Architecture: aarch64 (ARM64)
- Hardware: Parallels VM on Apple Silicon Mac
- Page Size: 4096 bytes

**Synchronet:**
- Version: 3.21b Debug
- Build: master/4089fb4 Jan 02 2026 02:23 with GCC 12.2.0
- Built from: Native ARM64 build (not QEMU emulated)

## Why Developer's RPi 500 Works

The Raspberry Pi 500 likely works because:
1. Raspberry Pi OS may use a memory layout that keeps allocations below the 47-bit boundary
2. Different kernel configuration for virtual address space
3. Possibly running 32-bit userspace (armhf) instead of 64-bit (aarch64)

## Technical Details

SpiderMonkey 1.8.5 uses NaN-boxing to store JavaScript values. In this scheme, 64-bit values are encoded as NaN floats, with pointers stored in the lower 47 bits of the mantissa. This works on x86_64 because Linux traditionally kept user-space addresses below 0x7fffffffffff (47 bits).

However, ARM64 Linux can use a larger virtual address space, allocating memory at addresses like `0xffffd2c04100` which requires 48 bits. When SpiderMonkey extracts the pointer using a 47-bit mask, it corrupts the address.

## Debug Backtrace

```
Thread 12 "sbbs/events" received signal SIGSEGV, Segmentation fault. 0x0000fffff6d06060 in JSObject::getClass (this=0x7fffd2c04100) at jsobj.h:427

#0 JSObject::getClass (this=0x7fffd2c04100) <- INVALID pointer (should be 0xffffd2c04100)
#1 JSObject::isFunction (this=0x7fffd2c04100)
#2 js::IsFunctionObject (v=...)
#3 js::FindClassPrototype (...)
v = {data = {debugView = {payload47 = 140736796311808, tag = JSVAL_TAG_OBJECT}}}
...
#14 js_InitFunctionClass (...)
#15 js_InitFunctionAndObjectClasses (...)
#16 JS_InitStandardClasses (...)
#17 js_CreateGlobalObject (...)
#18 js_CreateCommonObjects (...)
#19 sbbs_t::js_init (...)
#20 event_thread (...)
```

## Alternative Solutions

1. **Use `setarch --addr-compat-layout`** (RECOMMENDED - works now)
2. **Update to newer SpiderMonkey** - Newer versions handle 48+ bit pointers correctly
3. **Patch SpiderMonkey** - Modify the NaN-boxing code to use proper 48-bit pointer handling for ARM64
4. **Use 32-bit build** - armhf build would avoid the issue entirely

## Previous Theories (Ruled Out)

- **Pointer Authentication Code (PAC)**: Tested with `arm64.nopauth` kernel parameter - crash still occurred
- **Docker networking**: Crash occurs both inside and outside Docker
- **Library path issues**: RPATH verified correct, all libraries loading properly


Dockerfile used for debug build:
```
FROM debian:bookworm-slim

ENV DEBIAN_FRONTEND=noninteractive
ENV SBBSCTRL=/sbbs/ctrl
ENV SBBSEXEC=/sbbs/exec
ENV TERM=xterm

RUN apt-get update && apt-get install -y \
build-essential \
git \
libncurses-dev \
libnspr4-dev \
libcap-dev \
libarchive-dev \
pkg-config \
zip \
unzip \
perl \
python3 \
&& rm -rf /var/lib/apt/lists/*

# Clone Synchronet
RUN git clone --depth 1 https://gitlab.synchro.net/main/sbbs.git /sbbs

# Build main Synchronet (DEBUG build for better backtraces)
WORKDIR /sbbs/src/sbbs3
ENV SBBSDIR=/sbbs
RUN make SBBSDIR=/sbbs 2>&1 && \
echo "=== Main build completed (DEBUG) ===" && \
echo "=== Finding build directories ===" && \
ls -la /sbbs/src/sbbs3/ | grep gcc

# Copy executables from the MAIN build directory (not subdirectories)
# Debug builds may use different suffix - find the actual directory
RUN ARCH=$(uname -m | sed 's/x86_64/x64/' | sed 's/aarch64/aarch64/') && \
echo "Architecture: $ARCH" && \
echo "Looking for exe directories:" && \
find /sbbs/src/sbbs3 -maxdepth 1 -type d -name "gcc.linux.${ARCH}.*" && \
MAIN_EXE_DIR=$(find /sbbs/src/sbbs3 -maxdepth 1 -type d -name "gcc.linux.${ARCH}.exe.*" | head -1) && \
MAIN_LIB_DIR=$(find /sbbs/src/sbbs3 -maxdepth 1 -type d -name "gcc.linux.${ARCH}.lib.*" | head -1) && \
echo "Main exe dir: $MAIN_EXE_DIR" && \
echo "Main lib dir: $MAIN_LIB_DIR" && \
if [ -d "$MAIN_EXE_DIR" ]; then \
echo "Copying from main exe dir:" && \
ls -la "$MAIN_EXE_DIR" && \
cp -v "$MAIN_EXE_DIR"/* /sbbs/exec/; \
fi && \
if [ -d "$MAIN_LIB_DIR" ]; then \
echo "Copying from main lib dir:" && \
ls -la "$MAIN_LIB_DIR" && \
cp -v "$MAIN_LIB_DIR"/*.so /sbbs/exec/; \
fi

# Copy executables from subdirectory builds (scfg, uedit, umonitor, etc.)
RUN ARCH=$(uname -m | sed 's/x86_64/x64/' | sed 's/aarch64/aarch64/') && \
for subdir in scfg uedit umonitor; do \
EXE_DIR=$(find /sbbs/src/sbbs3/${subdir} -maxdepth 1 -type d -name "gcc.linux.${ARCH}.exe.*" 2>/dev/null | head -1); \
if [ -d "$EXE_DIR" ]; then \
echo "Copying from $EXE_DIR:" && \
cp -v "$EXE_DIR"/* /sbbs/exec/ 2>/dev/null || true; \
fi; \
done

# Verify key files exist
RUN echo "=== Contents of /sbbs/exec ===" && \
ls -la /sbbs/exec/sbbs /sbbs/exec/scfg /sbbs/exec/baja && \
echo "=== Checking rpath ===" && \
objdump -x /sbbs/exec/sbbs | grep -E 'R.*PATH' || echo "No RPATH found" && \
echo "=== Checking ldd ===" && \
ldd /sbbs/exec/sbbs

# Build doors/external programs (DEBUG)
WORKDIR /sbbs/src/doors
RUN for dir in */; do \
if [ -f "$dir/Makefile" ] || [ -f "$dir/GNUmakefile" ]; then \
echo "Building door: $dir"; \
make -C "$dir" 2>&1 || true; \
fi; \
done && \
echo "=== Doors build completed ==="

# Copy built door executables
RUN find /sbbs/src/doors -type f -executable -newer /sbbs/src/doors -exec file {} \; 2>/dev/null | \
grep "ELF" | cut -d: -f1 | while read f; do \
name=$(basename "$f"); \
dest_dir="/sbbs/xtrn/$name"; \
mkdir -p "$dest_dir" 2>/dev/null || true; \
cp "$f" "$dest_dir/" 2>/dev/null || cp "$f" /sbbs/xtrn/ 2>/dev/null || true; \
done

# Copy default config files
RUN cp -r /sbbs/ctrl.new/* /sbbs/ctrl/ 2>/dev/null || true
RUN cp -r /sbbs/text.new/* /sbbs/text/ 2>/dev/null || true

# Create required directories
RUN mkdir -p /sbbs/data /sbbs/ctrl /sbbs/text \
/sbbs/node1 /sbbs/node2 /sbbs/node3 /sbbs/node4 \
/sbbs/xtrn /sbbs/mods

# Add entrypoint
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

EXPOSE 513 23 22 80 443 21

WORKDIR /sbbs
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/sbbs/exec/sbbs"]
```
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8069

Thanks very much for this investigation, I'll take a look at the feasibility of adding a patch.

I had thought that the layout was only used by JIT via PunboxAssembler.h and since we disable JIT, we would not encounter the issue.
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8070

So, just took a look... while it's easy enough to extend the value to 48-bits by taking a bit from the tag, it appears that newer version of SpiderMonkey do *not* actually support more than 47 value bits

ie: `TAG_SHIFT` is still 47, and `bitsFromTagAndPayload()` is
```C++
static constexpr uint64_t bitsFromTagAndPayload(JSValueTag tag,
PayloadType payload) {
return (uint64_t(tag) << JSVAL_TAG_SHIFT) | payload;
}
```

So I'm not sure how Firefox and GNOME are getting away with this, though the `setarch` manpage perhaps has a hint:

```

-L, --addr-compat-layout
Provide legacy virtual address space layout. Use when the
program binary does not have PT_GNU_STACK ELF header. Turns on
ADDR_COMPAT_LAYOUT.
```

Is there some way to set `ADDR_COMPAT_LAYOUT` in the `PT_GNU_STACK` header via linker flags?
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8072

So, I didn't find any evidence that SpiderMonkey is using the `ADDR_COMPAT_LAYOUT` method, it it possible they're using a specific `mmap()` flag when allocating to constrain pointers to 47 bits?
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8073

I've added a call to `personality(ADDR_COMPAT_LAYOUT)` at the start of the `main()` functions for jsexec/jsdoor and sbbscon, so you should no longer need to use setarch.
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8158

@Deuce I'm having a problem with aarch64 which DM thought might be related to this thread.

I'm currently running SBBS in Proxmox on a CM5 in an LXC container running docker. (I've always run SBBS in docker, built using `bullseye-slim` as a base.)

Since docker under LXC is problematic, I thought I'd shift it to a Proxmox VM/QEMU (on the same CM5). I built a VM host running alpine.

The same container image (built a couple of months ago) that I was running in LXC, I used on the QEMU/VM segfaults upon startup.

I built a new debug image (as of git yesterday f28ef09d0) to get a backtrace - and started it, using default data (not my data, all initial defaults - thus a "new" SBBS BBS) and this is the backtrace:

```
[Current thread is 1 (Thread 0xfff32bfff1c0 (LWP 431))]
(gdb) bt
#0 0x0000fff34fbe1670 in JSObject::getClass (this=0x7ff32a804100) at jsobj.h:427
#1 0x0000fff34fbe22e8 in JSObject::isFunction (this=0x7ff32a804100) at jsfun.h:312
#2 0x0000fff34fcb3a94 in js::IsFunctionObject (v=...) at jsfun.h:342
#3 js::FindClassPrototype (cx=0xfff3240193e0, scopeobj=0xfff32a803048, protoKey=JSProto_Function, protop=0xfff32bff9e70, clasp=0xfff3500681e0 <js_FunctionClass>) at jsobj.cpp:6168
#4 0x0000fff34fcb3cf8 in js_GetClassPrototype (cx=0xfff3240193e0, scopeobj=0xfff32a803048, protoKey=JSProto_Function, protop=0xfff32bff9e70, clasp=0xfff3500681e0 <js_FunctionClass>)
at jsobj.cpp:6212
#5 0x0000fff34fc4f190 in js::FindProto (proto=0xfff32bff9e70, parent=0xfff32a804080, clasp=0xfff3500681e0 <js_FunctionClass>, cx=0xfff3240193e0) at jsobjinlines.h:1053
#6 js::detail::NewObject<false, true> (kind=js::gc::FINALIZE_OBJECT2, parent=0xfff32a804080, proto=0x0, clasp=0xfff3500681e0 <js_FunctionClass>, cx=0xfff3240193e0)
at jsobjinlines.h:1070
#7 js::NewFunction (parent=0xfff32a804080, cx=0xfff3240193e0) at jsobjinlines.h:1114
#8 js_NewFunction (cx=0xfff3240193e0, funobj=0x0, native=0xfff34fc4cd6c <fun_toSource(JSContext*, uintN, js::Value*)>, nargs=0, flags=0, parent=0xfff32a804080, atom=0xfff32a801640)
at jsfun.cpp:2729
#9 0x0000fff34fc4fa48 in js_DefineFunction (cx=0xfff3240193e0, obj=0xfff32a804080, id=281419855173184, native=0xfff34fc4cd6c <fun_toSource(JSContext*, uintN, js::Value*)>, nargs=0,
attrs=0) at jsfun.cpp:2960
#10 0x0000fff34fbdcff8 in JS_DefineFunction (cx=0xfff3240193e0, obj=0xfff32a804080, name=0xfff34ff14038 <js_toSource_str> "toSource",
call=0xfff34fc4cd6c <fun_toSource(JSContext*, uintN, js::Value*)>, nargs=0, attrs=4096) at jsapi.cpp:4477
#11 0x0000fff34fbdcf18 in JS_DefineFunctions (cx=0xfff3240193e0, obj=0xfff32a804080, fs=0xfff350068308 <function_methods>) at jsapi.cpp:4460
#12 0x0000fff34fcab43c in js::DefineConstructorAndPrototype (cx=0xfff3240193e0, obj=0xfff32a803048, key=JSProto_Function, atom=0xfff32a800380, protoProto=0x0,
clasp=0xfff3500681e0 <js_FunctionClass>, constructor=0xfff34fc4e070 <Function(JSContext*, uintN, js::Value*)>, nargs=1, ps=0x0, fs=0xfff350068308 <function_methods>, static_ps=0x0,
static_fs=0x0) at jsobj.cpp:3925
#13 0x0000fff34fcab7d0 in js_InitClass (cx=0xfff3240193e0, obj=0xfff32a803048, protoProto=0x0, clasp=0xfff3500681e0 <js_FunctionClass>,
constructor=0xfff34fc4e070 <Function(JSContext*, uintN, js::Value*)>, nargs=1, ps=0x0, fs=0xfff350068308 <function_methods>, static_ps=0x0, static_fs=0x0) at jsobj.cpp:4009
#14 0x0000fff34fc4ef10 in js_InitFunctionClass (cx=0xfff3240193e0, obj=0xfff32a803048) at jsfun.cpp:2683
#15 0x0000fff34fbd5c24 in js_InitFunctionAndObjectClasses (cx=0xfff3240193e0, obj=0xfff32a803048) at jsapi.cpp:1541
#16 0x0000fff34fbd5ea4 in JS_InitStandardClasses (cx=0xfff3240193e0, obj=0xfff32a803048) at jsapi.cpp:1596
#17 0x0000fff34faaa728 in js_CreateGlobalObject (cx=0xfff3240193e0, cfg=0xfff33c076958, methods=0xfff350064788 <js_global_functions>, startup=0xaaad3b44aba8 <bbs_startup+11800>,
glob=0xfff33c080860) at js_global.cpp:5459
#18 0x0000fff34fb103a0 in js_CreateCommonObjects (js_cx=0xfff3240193e0, cfg=0xfff350071dc8 <scfg>, node_cfg=0xfff33c076958, methods=0xfff350064788 <js_global_functions>,
uptime=1768991628, host_name=0xfff33c077b7f "mybbs.com", socklib_desc=0x0, cb=0xfff33c080880, js_startup=0xaaad3b44aba8 <bbs_startup+11800>, user=0xfff33c0819e8, client=0x0,
client_socket=-1, session=-1, props=0xfff350bb3920 <js_server_props>, glob=0xfff33c080860, mqtt=0xfff35007b810 <mqtt>) at main.cpp:1562
#19 0x0000fff34fb0ff94 in sbbs_t::js_init (this=0xfff33c0764f0, runtime=0xfff33c080850, glob=0xfff33c080860, desc=0xfff34ff030d8 "event") at main.cpp:1445
#20 0x0000fff34fb153a8 in event_thread (arg=0xfff33c0764f0) at main.cpp:2888 #21 0x0000fff34f7ad648 in start_thread (arg=0xfff32bffeac0) at pthread_create.c:477
#22 0x0000fff34f703c9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```

I've even tried running the container `privileged` and running sbbs as root to ensure there are no permission issues.

(Oh, if it is relevant, it started successfully using `NO_EVENTS`, and didnt segfault. I also tried the setarch thing but it still segfaulted.)

So there are two key differences here:
* Alpine host kernel (in QEMU/Docker) vs PVE/Debian host kernel (in LXC/Docker) * QEMU vs LXC

Any thoughts on how I can fix this? Happy to try things...
--- SBBSecho 3.35-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)