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)

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

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

Yes (SpiderMonkey v78).
--
digital man (rob)

This Is Spinal Tap quote #45:
I don't really think the end can be assessed as of itself as being the end Norco, CA WX: 64.0�F, 63.0% humidity, 4 mph WSW wind, 0.49 inches rain/24hrs --- 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
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.

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))
--- 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
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.
```
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))
--- 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)[](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))
--- 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)[](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))
--- 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)[](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))
--- 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)[](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))
--- 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_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?
--- 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_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!
--- 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_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.
--- 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)