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)