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

I was successfully able to build Synchronet on Debian Linux 12 aarch64 (arm64). The configuration command ``scfg`` works, but ``sbbs`` fails with either ``segmentation fault`` (when run without sudo permission), or ``permission denied to ctrl/*`` when run as sudo. This same behavior is observed even when all server ports are changed to non-privileged ports (like ``2323``, etc). It is also observed on the tag sbbs319b.

```
debianlinuxexp% uname -a
Linux debianlinuxexp 6.1.0-16-arm64 #1 SMP Debian 6.1.67-1 (2023-12-12) aarch64 GNU/Linux
```

1) Log for segfault (when run as non-root):
```
% SBBSCTRL=/home/aackmann/sbbs/ctrl SBBSEXEC=/home/aackmann/sbbs/exec XDG_RUNTIME_DIR=/home/aackmann/.cache/sbbs /home/aackmann/sbbs/exec/sbbs

Synchronet Console for Linux-armv8 Version 3.20a Copyright 2022 Rob Swindell

Reading /home/aackmann/sbbs/ctrl/sbbs.ini
Loading configuration files from /home/aackmann/sbbs/ctrl
!Started as non-root user (id 1000): May fail to bind TCP/UDP ports below 1024 12/19 10:42:37 term Synchronet Terminal Server Version 3.20a
12/19 10:42:37 term Compiled master/ded39adbd Dec 19 2023 08:10:52 with GCC 12.2.0
12/19 10:42:37 term Initializing on Tue Dec 19 10:42:37 2023 with options: 1022 12/19 10:42:37 term Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:42:37 web Synchronet Web Server Version 3.20a
12/19 10:42:37 web Compiled master/ded39adbd Dec 19 2023 08:11:29 with GCC 12.2.0
12/19 10:42:37 web Initializing on Tue Dec 19 10:42:37 2023 with options: 8a0 12/19 10:42:37 web Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:42:37 term Verifying/creating data directories
12/19 10:42:37 term Verifying/creating node directories
12/19 10:42:37 term Telnet Server listening on socket 0.0.0.0 port 2323
12/19 10:42:37 term Telnet Server listening on socket :: port 2323
12/19 10:42:37 term RLogin Server listening on socket 0.0.0.0 port 2325
12/19 10:42:37 term RLogin Server listening on socket :: port 2325
12/19 10:42:37 term SSH Server listening on socket 0.0.0.0 port 2324
12/19 10:42:37 term SSH Server listening on socket :: port 2324
12/19 10:42:37 web Web Server listening on socket 0.0.0.0 port 2400
12/19 10:42:37 web Web Server listening on socket :: port 2400
12/19 10:42:37 web Secure Web Server listening on socket 0.0.0.0 port 2401 12/19 10:42:37 evnt BBS Events BBS Events thread started
12/19 10:42:37 web Secure Web Server listening on socket :: port 2401
12/19 10:42:37 web Web Server thread started
12/19 10:42:37 term Node 1 local spy using socket /home/aackmann/.cache/sbbs/localspy1.sock
[Threads: 6 Sockets: 10 Clients: 0 Served: 0 Errors: 0] (?=Help): zsh: segmentation fault SBBSCTRL=/home/aackmann/sbbs/ctrl SBBSEXEC=/home/aackmann/sbbs/exec =
```
2) Permission issues when run as sudo:
```
% SBBSCTRL=/home/aackmann/sbbs/ctrl SBBSEXEC=/home/aackmann/sbbs/exec XDG_RUNTIME_DIR=/home/aackmann/.cache/sbbs sudo -E /home/aackmann/sbbs/exec/sbbs
[sudo] password for aackmann:

Synchronet Console for Linux-armv8 Version 3.20a Copyright 2022 Rob Swindell

Reading /home/aackmann/sbbs/ctrl/sbbs.ini
Loading configuration files from /home/aackmann/sbbs/ctrl
Current usr ids: ruid - 0, euid - 0, suid - 0
Current grp ids: rgid - 0, egid - 0, sgid - 0
The process 11317 was given capabilities =ep
Setting initial privileges
No password name for:
Successfully changed user-id to
Setting minimum privileges
Current usr ids: ruid - 0, euid - 0, suid - 0
Current grp ids: rgid - 0, egid - 0, sgid - 0
The process 11317 was given capabilities cap_net_bind_service,cap_sys_resource=ep
WARNING: No user account specified, running as root!
12/19 10:45:37 web Synchronet Web Server Version 3.20a
12/19 10:45:37 web Compiled master/ded39adbd Dec 19 2023 08:11:29 with GCC 12.2.0
12/19 10:45:37 web Initializing on Tue Dec 19 10:45:37 2023 with options: 8a0 12/19 10:45:37 term Synchronet Terminal Server Version 3.20a
12/19 10:45:37 term Compiled master/ded39adbd Dec 19 2023 08:10:52 with GCC 12.2.0
12/19 10:45:37 term Initializing on Tue Dec 19 10:45:37 2023 with options: 1022 12/19 10:45:42 web !ERROR 13 (Permission denied) changing directory to: /home/aackmann/sbbs/ctrl
12/19 10:45:42 web Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:45:42 term !ERROR 13 (Permission denied) changing directory to: /home/aackmann/sbbs/ctrl
12/19 10:45:42 term Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:45:52 term !ERROR 13 (Permission denied) opening /home/aackmann/sbbs/ctrl/main.ini
12/19 10:45:57 web !ERROR 13 (Permission denied) opening /home/aackmann/sbbs/ctrl/msgs.ini
12/19 10:45:57 term !FAILED to load configuration files
12/19 10:45:57 term Terminal Server thread terminating
12/19 10:45:57 term Terminal Server thread terminated (0 clients served)
12/19 10:46:02 web !FAILED to load configuration files
12/19 10:46:02 web #### Web Server thread terminated (0 clients served, 0 concurrently)
[Threads: 2 Sockets: 0 Clients: 0 Served: 0 Errors: 6] (?=Help): q
```
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

For the first issue (segfault), can you provide a backtrace following this how-to guidehttps://wiki.synchro.net/howto:gdb ?

For the second issue (please file as separate issues in the future), who owns the files in question and what are the permission modes on those file? This doesn't seem like an sbbs issue on the surface.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

@rswindell Sure, here's the gdb output I could capture:

[gdb_no_threadapplyallbt.txt](/uploads/4853285e094cd9e5fc56ed9dd6f35e7c/gdb_no_threadapplyallbt.txt)

[gdb_with_threadapplyallbt.txt](/uploads/d56989934d69788062b0c20ea5e12d82/gdb_with_threadapplyallbt.txt)

Ok, I don't see the permission issue on another VM. Will investigate what's the problem, even though all files are aackmann:aackmann in that directory. One thing that was different while building it was that your installer hadn't asked me for a password for setcap. So on the failing machine, when I ran make it was already built with sudo permissions. The machine on which it doesn't fail, the make install command stopped for me to enter the password.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

According to that backtrace, it's crashing in /lib/libmozjs185.so.1.0

Can you try building/using the libmozjs from the source provided in the sbbs repo instead? It's been patched (by someone) to build for arm64 and presumably was tested: https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/build/js-config.guess.patch?ref_type=heads
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

@rswindell It isn't clear how to build it build https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/dist/libmozjs.tgz, and how to apply https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/build/js-config.guess.patch?ref_type=heads to that...

Here's a screenshot that shows all file paths matching "mozjs" in your repo. Is there a make flag, build script, or instructions to build this? (this [documentation](https://firefox-source-docs.mozilla.org/js/build.html) from Mozilla isn't clear) Also it isn't clear if the patches were already applied to produce https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/dist/libmozjs.tgz.

--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Building/using the libmozjs from the sbbs git repo is the *default* build behavior. According to the backtrace you supplied, your sbbs is linking with/using `/lib/libmozjs185.so.1.0`, so that implies you're not doing the default thing.

Likely, you're specifying JSLIB and JSINCLUDE options on your make command-line (as instructed to do on https://wiki.synchro.net/howto:raspbian_install) - just removing those 2 options from your make command-line should force the build to compile and link with the libmozjs included in the repo. The patches are applied automatically.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

@rswindell Now I get config.status error. Since it seems to have been patched (see the files "config.guess" files below), I am not sure what to do to them... My system is a aarch64 linux (non raspberry pi).


```
repo/3rdp/build/js-config.guess.patch repo/3rdp/src/mozjs/js-1.8.5/js/src/build/autoconf/config.guess.orig repo/3rdp/src/mozjs/js-1.8.5/js/src/build/autoconf/config.guess repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi/config.guess
```

Please check the errors below:

```
$ SBBSEXEC=/home/aackmann/sbbs/exec make install SYMLINK=1
...
creating Makefile
creating shell/Makefile
creating lirasm/Makefile
creating jsapi-tests/Makefile
creating tests/Makefile
creating config/Makefile
creating config/mkdepend/Makefile
creating editline/Makefile
updating cache ./config.cache
creating ./config.status
creating config/autoconf.mk
creating js-config.h
invoking make to create js-config script
gmake[3]: Entering directory '/home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src'
rm -f js-config.tmp
sed < js-config.in > js-config.tmp \
-e 's|@prefix@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs|' \
-e 's|@exec_prefix@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs|' \
-e 's|@includedir@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/include|' \
-e 's|@libdir@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/lib|' \
-e 's|@MOZILLA_VERSION@||' \
-e 's|@LIBRARY_NAME@|mozjs185|' \
-e 's|@NSPR_CFLAGS@|-I/usr/include/nspr|' \
-e 's|@JS_CONFIG_LIBS@|-Wl,--whole-archive ctypes/libffi/.libs/libffi.a -Wl,--no-whole-archive -L/usr/lib/aarch64-linux-gnu -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lm -ldl |' \
-e 's|@MOZ_JS_LIBS@|-L/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/lib -lmozjs185|' \
&& mv js-config.tmp js-config && chmod +x js-config
gmake[3]: Leaving directory '/home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src'
configuring in ctypes/libffi
running /bin/sh ./configure --disable-shared --enable-static --disable-raw-api --with-pic --cache-file=/home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi/config.cache --srcdir=.
configure: creating cache /home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi/config.cache
checking build system type... ./config.guess: unable to guess system type

This script, last modified 2009-11-19, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed information to handle your system.

config.guess timestamp = 2009-11-19

uname -m = aarch64
uname -r = 6.1.0-16-arm64
uname -s = Linux
uname -v = #1 SMP Debian 6.1.67-1 (2023-12-12)

/usr/bin/uname -p = unknown
/bin/uname -X =

hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch = aarch64
/usr/bin/oslevel =
/usr/convex/getsysinfo =

UNAME_MACHINE = aarch64
UNAME_RELEASE = 6.1.0-16-arm64
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP Debian 6.1.67-1 (2023-12-12)
configure: error: cannot guess build type; you must specify one
configure: error: ./configure failed for ctypes/libffi
make[2]: *** [GNUmakefile:77: ../build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/lib/libmozjs185-1.0.a] Error 1
make[2]: Leaving directory '/home/aackmann/sbbs/repo/3rdp/build'
make[1]: *** [/home/aackmann/sbbs/repo/src/sbbs3/../build/Common.gmake:553: js] Error 2
make[1]: Leaving directory '/home/aackmann/sbbs/repo/src/sbbs3'
make: *** [GNUmakefile:152: sbbs3] Error 2
```
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

From the error, it looks like a problem with build/using libffi (e.g. "`configuring in ctypes/libffi`). If you install the appropriate libffi package for your platform (as shown on https://wiki.synchro.net/howto:raspbian_install), perhaps you can avoid that build/problem?

If that doesn't work, perhaps the `js/src/ctypes/libffi/config.guess` will need similar patch as was done for `js/src/build/autoconf/config.guess`.

Someday (not soon), we'll upgrade to a newer libmozjs and not have so many aarch64 issues.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

@rswindell I have libffi, and libmozjs installed on my system. I don't know what make variable to use to nudge GNUmakefile to pick system libffi but your packaged libmozjs. How to do that? I had installed all the 3 packages mentioned on rasping_install page on my Debian machine. Not from the same links though, as those are armhf libraries, whereas I have arm64 architecture. Also it was a pain to find mozjs185, as most links were marked deprecated, deleted, etc. My system has libffi.so.6.0.4, and libffi.so.8.1.2.

```
debianlinuxexp% ls -lrta /usr/lib/libffi*
-rw-r--r-- 1 root root 68000 Dec 22 05:08 /usr/lib/libffi.so.8.1.2
-rw-r--r-- 1 root root 68000 Dec 22 05:08 /usr/lib/libffi.so.8
-rw-r--r-- 1 root root 31016 Dec 22 05:08 /usr/lib/libffi.so.6.0.4
-rw-r--r-- 1 root root 31016 Dec 22 05:08 /usr/lib/libffi.so.6
-rw-r--r-- 1 root root 68000 Dec 22 05:08 /usr/lib/libffi.so
-rw-r--r-- 1 root root 49334 Dec 22 05:08 /usr/lib/libffi_pic.a
-rw-r--r-- 1 root root 49638 Dec 22 05:08 /usr/lib/libffi.a
```
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

I would like to offer testing support for making macOS client /Linux BBS client/server experience much better

Synchronet doesn't currently support macOS, but SyncTERM does, but since most of us don't own modern Macs, it's kind of a pain. Deuce (main maintainer of SyncTERM) could probably use a modern macOS build/test system, if you can offer him remote access.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs binary: Debian Linux AARCH64 sigfault or permission denied
By: Rob Swindell to GitLab note in main/sbbs on Tue Dec 26 2023 04:52 pm

Howdy,

Synchronet doesn't currently support macOS, but SyncTERM does, but since most of us don't own modern Macs, it's kind of a pain. Deuce (main maintainer of SyncTERM) could probably use a modern macOS build/test system, if you can offer him remote access.

I've offered in the past, and happy to offer again, although it might not be useful.

I can run a gitlab-ci agent on a MAC m1 machine (it'll be inside docker, which I guess is technically linux aarch64) - that can run jobs...

If you need macOS, if there is a way that it can be jailed to a VM on my M1, then I'm happy to take a look.

(I used to run VMs on an Intel mac with VMware, but there is little information about running on M1. That said, I just found this...https://github.com/KhaosT/MacVM).


...����

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

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

If you update config.guess and config.sub in /sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi with the latest version then you get this error:

configure: error: "libffi has not been ported to aarch64-unknown-linux-gnu." configure: error: ./configure failed for ctypes/libffi

Considering the aarch64 architecture uses arm64 packages, we should be able to force it to build for that.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

I built libmoz locally from the launchpad sources and the debian patches and still get the coredump but there's more information in the bt.

https://pastebin.com/GBnpfz6X
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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