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)[](url[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))

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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)[](url[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))

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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)[](url[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))

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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)[](url[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))

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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))

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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)

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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)

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

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
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

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?

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Correct - running with no events resolves the seg fault.

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Are there any ARM64/aarch64-specific patches that should be applied but aren't in the current patch set?

No, all patches are unconditional.

Is there a known issue with js_GetClassPrototype() on ARM64 with this version of SpiderMonkey?

No, we haven't seen issues on other systems, and have been using this for quite a while.

The build uses `--with-system-nspr` — could there be an incompatibility between system NSPR (from Debian) and the SpiderMonkey build on ARM64?

I would be very shocked, NSPR4 has been an exceptionally stable API for a very long time. They do it right, and I trust them a lot.

Could there be an issue with the libffi ARM64 calling conventions?

The build should be completely replacing the included libffi with the one in `3rdp/dist` (v3.5.2) before the build. If looking at newer releases of libffi suggests something has changed, you should be able to test by simply swapping libffi.tgz out there.

I'll dig into this info, thanks for following up!

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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:

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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`)

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

To check the rpath:
`objdump -x /sbbs/exec/sbbs | grep 'R.*PATH'`

It should have the build path listed first, then `$ORIGIN`... which would suggest that the built versions have been deleted?

Ah, looking at the build output, it's adding `/sbbs/exec` first, so it's critical these are the same as the built versions.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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...

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

It's also useful to have the actual error with the backtrace (though I assume it's a segfault).

Did you try the setenv thing?

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Oh, another thing to check is that the program isn't setuid.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Also, `cat /proc/[PID]/personality` should print `00200000` if the `personality()` call succeeded.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

`setenv` thing, did you mean `setarch`? And yes, I did try that...

The actual backtrace is above, or did you mean something else?

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

It doesnt appear to be

```
root@419aa74cc0e0:/opt/sbbs# ls -al /opt/sbbs/exec/sbbs
-rwxr-xr-x 1 root root 192928 Jan 20 22:59 /opt/sbbs/exec/sbbs
```

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

I cant do this, as it coredumps almost immediately.

However, if I start it with NO_EVENTs, then:

```
sbbs -t-

[in another window]
root@8e025d59d208:/opt/sbbs# ps -Af
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 18:33 pts/0 00:00:00 bash
root 16 1 0 18:33 pts/0 00:00:00 sbbs -t-
root 25 0 0 18:34 pts/1 00:00:00 bash
root 31 25 0 18:34 pts/1 00:00:00 ps -Af root@8e025d59d208:/opt/sbbs# cat /proc/16/personality
00200000
```

Container is started with `docker run -it --rm --privileged=true local/sbbs bash`

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Hrm, so this is likely an issue with `TASK_UNMAPPED_BASE` possibly due to a large `TASK_SIZE`. Not sure if these can be configured at runtime or if they're set when the kernel is compiled, digging a bit more.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Is the kernel using 64k pages? You can check with `getconf PAGESIZE`. If so, possibly changing to a 4k page kernel will solve the problem.

If not, I can try forcing an mmap() and hope it grows down from there.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Another possible option would be disabling ASLR... simply adding ` | ADDR_NO_RANDOMIZE` to the `personality()` call in `sbbscon.c` should do that.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

I've committed a change that adds commented-out code with the two possibilities in sbbscon.c. Can you play with them and see if any of the three by itself is sufficient, or worst case, if a combination of the third (mmap) and one of the first two works?

Order of preference:
1. mmap
2. mmap + personality() leaving ASLR enabled
3. personality() disabling ASLR
4. mmap + personality() disabling ASLR

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Looks like 4K.

```
root@65153ed9ef70:/opt/sbbs# getconf PAGESIZE
4096
```

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

OK, no success:

* Only `personality(ADDR_COMPAT_LAYOUT | PER_LINUX);` (as per checkout), coredump on the same line:
```
#0 0x0000fffc84bcad88 in JSObject::getClass (this=0x7ffc5b404100) at jsobj.h:427
```

* Only `personality(ADDR_COMPAT_LAYOUT | ADDR_NO_RANDOMIZE | PER_LINUX);` coredump on the same line
```
#0 0x0000fffb214a2d88 in JSObject::getClass (this=0x7ffaf7e04100) at jsobj.h:427
```

* Only ` void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);` compile errors:
```
Compiling sbbscon.c
sbbscon.c: In function 'main':
sbbscon.c:1211:25: warning: implicit declaration of function 'mmap' [-Wimplicit-function-declaration]
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~
sbbscon.c:1211:65: error: 'PROT_NONE' undeclared (first use in this function); did you mean 'XLAT_NONE'?
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~
| XLAT_NONE
sbbscon.c:1211:65: note: each undeclared identifier is reported only once for each function it appears in
sbbscon.c:1211:76: error: 'MAP_PRIVATE' undeclared (first use in this function); did you mean 'LP_PRIVATE'?
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~~~
| LP_PRIVATE
sbbscon.c:1211:90: error: 'MAP_ANONYMOUS' undeclared (first use in this function); did you mean 'MSG_ANONYMOUS'?
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~~~~~
| MSG_ANONYMOUS
sbbscon.c:1211:106: error: 'MAP_FIXED_NOREPLACE' undeclared (first use in this function)
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~~~~~~~~~~~
sbbscon.c:1211:15: warning: unused variable 'hackPtr' [-Wunused-variable]
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~
make[1]: *** [/opt/sbbs/repo/src/sbbs3/../build/Common.gmake:568: gcc.linux.aarch64.obj.debug-mt/sbbscon.o] Error 1
```

Did I do it right? Each build was run with `make -f install-sbbs.mk DEBUG=1 NO_X=1 SBBSDIR=/opt/sbbs`

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Yeah, you did it right, I fogot to add the include file for mmap. Just pushed a new change with that fix in it, so mmap() should be usable.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

OK:

* only `void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);` still core dumps
```
#0 0x0000fffb9d509d88 in JSObject::getClass (this=0x7ffb83e04100) at jsobj.h:427
```

* `void ...` + `personality(ADDR_COMPAT_LAYOUT | PER_LINUX);`
```
#0 0x0000fffbe7284d88 in JSObject::getClass (this=0x7ffbd9c04100) at jsobj.h:427
```

* `void ...` + `personality(ADDR_COMPAT_LAYOUT | ADDR_NO_RANDOMIZE | PER_LINUX);`
```
#0 0x0000fffc59921d88 in JSObject::getClass (this=0x7ffc54204100) at jsobj.h:427
```

No cigar ;(

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Ok, so fundamentally what we need to do is to get the used memory locations below `0x00007fffffffffff`.

The nuclear option here is to add ` | ADDR_LIMIT_32BIT` to the `personality()` call, which should limit the Synchronet memory space to around 3GB.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

The Google AI us suggesting various things that may or may not work to have the QEMU restrict the address space appropriately. I'm not familiar enough with Proxmox or QEMI aarch64 to evaluate how garbage the suggestions are.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

The Google AI is suggesting various things that may or may not work to have the QEMU restrict the address space appropriately. I'm not familiar enough with Proxmox or QEMI aarch64 to evaluate how garbage the suggestions are.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

The one that looks most promising is running sbbs using prlimit as `prlimit --as=140737488355327 /path/to/sbbs`. If this works, you can configure the limit for the user in `/etc/security/limits.conf`.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

PROT_NONE = pages may not be accessed = segfault

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

No cigar here either :disappointed: Tried the `prlimit` and `ADDR_LIMIT_32BIT`...

Going along with the memory thing, I also reduced the VM to 2GIG it didnt help either.

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Can you try setting the 32-bit personality using `setarch -B`? It's almost certainly "too late" for it to be attempted in `main()` itself since that address of `main()` will be something like `0x0000fffffffff284` which is already outside of the 32-bit space.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Finally found the [upstream issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1143022). I'll dig into this in the next couple days and see if a reasonable patch can be added.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Just pushed SpiderMonkey patch that may resolve the issue. At the very least, it shouldn't crash anymore, so it should either work or complain that it can't allocate anything.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Yep, hackPtr is never accessed.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Still core dumps on start - but looks like a different backtrace

```
#0 0x0000fff083d955f8 in JSString::isRope (this=0x7ff0841c15b0) at jsstr.h:217 #1 JSString::ensureLinear (this=0x7ff0841c15b0, cx=0xfff0580193e0) at jsstr.h:366
#2 0x0000fff083ecfe5c in ArgToRootedString (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00280, arg=1) at jsstr.cpp:360
#3 0x0000fff083edabc0 in js::str_replace (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00268) at jsstr.cpp:2489
#4 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00268, argc=2, native=0xfff083eda51c <js::str_replace(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#5 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea001b8, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#6 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff05807c150, fp=0xfff05ea001b8) at jsinterp.cpp:653
#7 0x0000fff083e3b3b4 in js::Invoke (cx=0xfff0580193e0, argsRef=..., flags=16384) at jsinterp.cpp:740
#8 0x0000fff083e00f60 in js_fun_apply (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00170) at jsfun.cpp:2205
#9 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00170, argc=2, native=0xfff083e00a2c <js_fun_apply(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#10 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea00118, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#11 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff058090440, fp=0xfff05ea00118) at jsinterp.cpp:653
#12 0x0000fff083e3cde8 in js::Execute (cx=0xfff0580193e0, chain=0x700000031360, script=0xfff058090440, prev=0x0, flags=0, result=0xfff05ffc5148) at jsinterp.cpp:1028
#13 0x0000fff083d91ad0 in JS_ExecuteScript (cx=0xfff0580193e0, obj=0x700000031360, scriptObj=0x700000031708, rval=0xfff05ffc5148) at jsapi.cpp:4998
#14 0x0000fff083c4790c in js_load (cx=0xfff0580193e0, argc=3, arglist=0xfff05ea000a8) at js_global.cpp:707
#15 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea000a8, argc=3, native=0xfff083c45660 <js_load(JSContext*, uintN, jsval*)>, cx=0xfff0580193e0) at jscntxtinlines.h:701
```

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Still core dumps on start - but looks like a different backtrace

```
#0 0x0000fff083d955f8 in JSString::isRope (this=0x7ff0841c15b0) at jsstr.h:217 #1 JSString::ensureLinear (this=0x7ff0841c15b0, cx=0xfff0580193e0) at jsstr.h:366
#2 0x0000fff083ecfe5c in ArgToRootedString (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00280, arg=1) at jsstr.cpp:360
#3 0x0000fff083edabc0 in js::str_replace (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00268) at jsstr.cpp:2489
#4 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00268, argc=2, native=0xfff083eda51c <js::str_replace(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#5 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea001b8, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#6 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff05807c150, fp=0xfff05ea001b8) at jsinterp.cpp:653
#7 0x0000fff083e3b3b4 in js::Invoke (cx=0xfff0580193e0, argsRef=..., flags=16384) at jsinterp.cpp:740
#8 0x0000fff083e00f60 in js_fun_apply (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00170) at jsfun.cpp:2205
#9 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00170, argc=2, native=0xfff083e00a2c <js_fun_apply(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#10 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea00118, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#11 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff058090440, fp=0xfff05ea00118) at jsinterp.cpp:653
#12 0x0000fff083e3cde8 in js::Execute (cx=0xfff0580193e0, chain=0x700000031360, script=0xfff058090440, prev=0x0, flags=0, result=0xfff05ffc5148) at jsinterp.cpp:1028
#13 0x0000fff083d91ad0 in JS_ExecuteScript (cx=0xfff0580193e0, obj=0x700000031360, scriptObj=0x700000031708, rval=0xfff05ffc5148) at jsapi.cpp:4998
#14 0x0000fff083c4790c in js_load (cx=0xfff0580193e0, argc=3, arglist=0xfff05ea000a8) at js_global.cpp:707
#15 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea000a8, argc=3, native=0xfff083c45660 <js_load(JSContext*, uintN, jsval*)>, cx=0xfff0580193e0) at jscntxtinlines.h:701
#16 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea00048, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#17 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff05807b4e0, fp=0xfff05ea00048) at jsinterp.cpp:653
#18 0x0000fff083e3cde8 in js::Execute (cx=0xfff0580193e0, chain=0x700000031360, script=0xfff05807b4e0, prev=0x0, flags=0, result=0xfff05ffcb240) at jsinterp.cpp:1028
#19 0x0000fff083d91ad0 in JS_ExecuteScript (cx=0xfff0580193e0, obj=0x700000031360, scriptObj=0x7000000313a8, rval=0xfff05ffcb240) at jsapi.cpp:4998
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x0000fff083bca578 in sbbs_t::js_execfile (this=0xfff074078cc0, cmd=0xfff07408bafa "logonlist -m", startup_dir=0xfff0840b6750 "", scope=0x0, js_cx=0xfff0580193e0,
js_glob=0x700000003048) at exec.cpp:692
#21 0x0000fff083d5fe24 in sbbs_t::external (this=0xfff074078cc0, cmdline=0xfff07408baf9 "?logonlist -m", mode=256, startup_dir=0xfff0840b6750 "") at xtrn.cpp:1169
#22 0x0000fff083cd2740 in sbbs_t::daily_maint (this=0xfff074078cc0) at main.cpp:4891
#23 0x0000fff083cc76f8 in event_thread (arg=0xfff074078cc0) at main.cpp:3107 #24 0x0000fff083902648 in start_thread (arg=0xfff05fffeac0) at pthread_create.c:477
#25 0x0000fff083858c9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Yeah, I have a theory of what's happening here, can you try running this build using `setarch --addr-compat-layout`?

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Added a few new commits so you don't need to use `setarch`. :slight_smile:

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Winner :smile:

At first glance, sbbs starts and doesnt segfault. This is a vanilla environment compiled from `master/a90a05372`. I'll compile a clean container, without `DEBUG=1` to do more tests.

I did have to start the container privileged, I dont have the error on hand but from memory it was something like `personality(): permission denied` (and I was root at the time in the container). Would you know off the top of your head what capability it needs, so I dont have to give it privileged?

Appreciate your help in getting this working - thank you.

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

The error when not running privileged is `personality() failed: Operation not permitted`

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

I don't even know what the set of capabilities is or where that's documented. :grinning:

The changes basically:
1. Read the current personality using `personality(0xffffffff)`.
2. Set the new personality using `personality(ADDR_COMPAT_LAYOUT | current_personality)`
3. Re-executes itself using the `/proc/self/exe` symlink.

From the message, it sounds like either 1 or 2 is being blocked. There's a lot of other things `personality()` can potentially do, such as disabling ASLR which something may be blocking the function completely over without inspecting the value.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

AI tells me this:

**1. Seccomp Permission**
The default Docker Seccomp Profile returns EPERM (Operation not permitted) for personality() unless it is called with specific, safe flags (like those used for uname emulation). ADDR_COMPAT_LAYOUT is generally not in this "safe" allowlist.
_Recommendation:_ Use --security-opt seccomp=unconfined to verify if this is the only blocker.
_Production Fix:_ Create a Custom Seccomp Profile that adds personality to the syscalls allowlist without restrictions on the arguments.

**2. Capabilities**
While some personality() flags are unprivileged, modifying the memory layout of a process can sometimes be gated by CAP_SYS_ADMIN depending on the specific kernel version and architecture-specific security patches.
_Requirement:_ Add the capability using --cap-add=SYS_ADMIN.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

Deon George wrote to GitLab note in main/sbbs <=-

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

The error when not running privileged is `personality() failed:
Operation not permitted`

My guess would be that it's trying to bind to a port < 1024.



... Gone crazy, be back later, please leave message.
--- MultiMail/Linux v0.52
� Synchronet � Palantir BBS * palantirbbs.ddns.net * Pensacola, FL

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

Dang, I was posting some testing updates, that I must not have submitted.

I did some AI searching too (because this is all foreign to me), and AI told me it was related to ASLR (whatever that is).

I tried `--cap-add=SYS_ADMIN` without success, and even `--security-opt seccomp=unconfined`, which it started then segfaulted again.

```
(gdb) bt
#0 0x0000400001418d6c in cleanup(int, int) [clone .constprop.0] () from /opt/sbbs/exec/libftpsrvr.so
#1 0x000040000141d9d4 in ftp_server () from /opt/sbbs/exec/libftpsrvr.so
#2 0x0000400001526648 in start_thread (arg=0x40000539aac0) at pthread_create.c:477
#3 0x0000400001621c9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```

(This time ftp_server is the second line, a previous start it was mail_server.)

As I worked throught it with AI, it tells me:
```
If --security-opt seccomp=unconfined allows the application to proceed but it immediately segfaults, you have likely moved from a "permissions" problem to a "compatibility" or "memory mapping" problem.

Likely Causes for the Segfault
Architecture Mismatch (Emulation Issues): [NO LIKELY? since its qemu aarch64 on aarch64].

GDB / Debugger Conflicts: If you are using a debugger like GDB, it calls personality(ADDR_NO_RANDOMIZE) to make memory addresses deterministic. If the application's internal memory management expects randomized addresses (or vice-versa), it can crash.

Invalid Memory Access: The application may be attempting to access a memory address that is only valid in a specific "personality" (like a 32-bit address space), but failing to map that memory correctly once the syscall succeeds.
```

I tried the recommended `echo 0 | sudo tee /proc/sys/kernel/randomize_va_space` no change.

Looks like I might be stuck with `privileged` mode :( (But happy it looks like its working.)

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

So, that segfault does not appear to be Javascript related at all, so is likely a different issue.

All three of those AI suggestions appear to be hogwash.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

Re: Re: sbbs binary: Debian Linux AARCH64 sigfault or permission denied
By: Gamgee to Deon George on Fri Feb 27 2026 08:29 am

Howdy,

The error when not running privileged is `personality() failed: Operation not permitted`

My guess would be that it's trying to bind to a port < 1024.

Nope, its running as root.


...����

---
� Synchronet � AnsiTEX bringing back videotex but with ANSI

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

Yeah, sometimes AI is helpful, sometimes its not - fair enough.. :smile:

Do you want a debug backtrace for that segfault - in case it is a different issue?

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Apologies... I never followed up after I got my similar issue above working. Hopefully this will help you.

My working container build https://github.com/jagould2012/cyberdeck/blob/main/bbs/Dockerfile

My branch with debug output and stacktrace capture that I used to track the issue down
https://github.com/jagould2012/cyberdeck/blob/feature/bbs-arm64-testing/bbs/Dockerfile.arm64-debug

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

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

Always want a debug backtrace of any segfault, yes please.

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net

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

Here you go:

```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 std::__atomic_base<unsigned int>::load (__m=std::memory_order_seq_cst, this=0x4) at /usr/include/c++/10/bits/atomic_base.h:426
426 /usr/include/c++/10/bits/atomic_base.h: No such file or directory. [Current thread is 1 (Thread 0x400005cc61c0 (LWP 11))]
(gdb) bt
#0 std::__atomic_base<unsigned int>::load (__m=std::memory_order_seq_cst, this=0x4) at /usr/include/c++/10/bits/atomic_base.h:426
#1 std::__atomic_base<unsigned int>::operator unsigned int (this=0x4) at /usr/include/c++/10/bits/atomic_base.h:289
#2 0x00004000015c5f58 in cleanup (code=1) at mailsrvr.cpp:6094
#3 0x00004000015c6e20 in mail_server (arg=0xaaaaaaacd5d8 <mail_startup>) at mailsrvr.cpp:6295
#4 0x0000400001650648 in start_thread (arg=0x400005cc5ac0) at pthread_create.c:477
#5 0x000040000174bc9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```

Oh wait, I just discovered the possible reason (but it shouldnt segfault anyway?).

I started my container without initialising the configuration (so no ctrl/ dir) - so it earlier complains about:

```
3/1 21:42:58 term !ERROR loading configuration files: ERROR 2 (No such file or directory) opening /opt/sbbs/ctrl/main.ini
3/1 21:42:58 term Terminal Server thread terminating
3/1 21:42:58 srvc !ERROR loading configuration files: 2 opening /opt/sbbs/ctrl/text.dat
[Threads: 5 Sockets: 0 Clients: 0 Served: 0 Errors: 2] (?=Help): Segmentation fault (core dumped)
```

When I initialised the configuration (which puts in place ctrl it stays running :)

---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net