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

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

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

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

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

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

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

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

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

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

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

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

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

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

Did you try the setenv thing?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Oh, another thing to check is that the program isn't setuid.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Also, `cat /proc/[PID]/personality` should print `00200000` if the `personality()` call succeeded.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

The actual backtrace is above, or did you mean something else?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

It doesnt appear to be

```
root@419aa74cc0e0:/opt/sbbs# ls -al /opt/sbbs/exec/sbbs
-rwxr-xr-x 1 root root 192928 Jan 20 22:59 /opt/sbbs/exec/sbbs
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

I cant do this, as it coredumps almost immediately.

However, if I start it with NO_EVENTs, then:

```
sbbs -t-

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

Container is started with `docker run -it --rm --privileged=true local/sbbs bash`
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Hrm, so this is likely an issue with `TASK_UNMAPPED_BASE` possibly due to a large `TASK_SIZE`. Not sure if these can be configured at runtime or if they're set when the kernel is compiled, digging a bit more.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

If not, I can try forcing an mmap() and hope it grows down from there.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Another possible option would be disabling ASLR... simply adding ` | ADDR_NO_RANDOMIZE` to the `personality()` call in `sbbscon.c` should do that.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

Order of preference:
1. mmap
2. mmap + personality() leaving ASLR enabled
3. personality() disabling ASLR
4. mmap + personality() disabling ASLR
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Looks like 4K.

```
root@65153ed9ef70:/opt/sbbs# getconf PAGESIZE
4096
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

OK, no success:

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

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

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

Did I do it right? Each build was run with `make -f install-sbbs.mk DEBUG=1 NO_X=1 SBBSDIR=/opt/sbbs`
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Yeah, you did it right, I fogot to add the include file for mmap. Just pushed a new change with that fix in it, so mmap() should be usable.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

OK:

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

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

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

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

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

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

The nuclear option here is to add ` | ADDR_LIMIT_32BIT` to the `personality()` call, which should limit the Synchronet memory space to around 3GB.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

The Google AI us suggesting various things that may or may not work to have the QEMU restrict the address space appropriately. I'm not familiar enough with Proxmox or QEMI aarch64 to evaluate how garbage the suggestions are.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

The Google AI is suggesting various things that may or may not work to have the QEMU restrict the address space appropriately. I'm not familiar enough with Proxmox or QEMI aarch64 to evaluate how garbage the suggestions are.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

The one that looks most promising is running sbbs using prlimit as `prlimit --as=140737488355327 /path/to/sbbs`. If this works, you can configure the limit for the user in `/etc/security/limits.conf`.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

PROT_NONE = pages may not be accessed = segfault
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

Going along with the memory thing, I also reduced the VM to 2GIG it didnt help either.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Can you try setting the 32-bit personality using `setarch -B`? It's almost certainly "too late" for it to be attempted in `main()` itself since that address of `main()` will be something like `0x0000fffffffff284` which is already outside of the 32-bit space.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Finally found the [upstream issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1143022). I'll dig into this in the next couple days and see if a reasonable patch can be added.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Just pushed SpiderMonkey patch that may resolve the issue. At the very least, it shouldn't crash anymore, so it should either work or complain that it can't allocate anything.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Yep, hackPtr is never accessed.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

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

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

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

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

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

Yeah, I have a theory of what's happening here, can you try running this build using `setarch --addr-compat-layout`?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Added a few new commits so you don't need to use `setarch`. :slight_smile:
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Winner :smile:

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

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

Appreciate your help in getting this working - thank you.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

The error when not running privileged is `personality() failed: Operation not permitted`
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

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

From the message, it sounds like either 1 or 2 is being blocked. There's a lot of other things `personality()` can potentially do, such as disabling ASLR which something may be blocking the function completely over without inspecting the value.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

AI tells me this:

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

**2. Capabilities**
While some personality() flags are unprivileged, modifying the memory layout of a process can sometimes be gated by CAP_SYS_ADMIN depending on the specific kernel version and architecture-specific security patches.
_Requirement:_ Add the capability using --cap-add=SYS_ADMIN.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

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

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



... Gone crazy, be back later, please leave message.
--- MultiMail/Linux v0.52
� Synchronet � Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

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

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

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

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

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

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

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

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

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

Looks like I might be stuck with `privileged` mode :( (But happy it looks like its working.)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

All three of those AI suggestions appear to be hogwash.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Howdy,

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

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

Nope, its running as root.


...����

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

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

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

Do you want a debug backtrace for that segfault - in case it is a different issue?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

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

My branch with debug output and stacktrace capture that I used to track the issue down
https://github.com/jagould2012/cyberdeck/blob/feature/bbs-arm64-testing/bbs/Dockerfile.arm64-debug
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Always want a debug backtrace of any segfault, yes please.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Here you go:

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

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

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

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

When I initialised the configuration (which puts in place ctrl it stays running :)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)