home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   SYNC_SYSOPS      Synchronet Multinode BBS Software Suppor      33,243 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,935 of 33,243   
   Jonathan Gould to GitLab note in main/sbbs   
   sbbs binary: Debian Linux AARCH64 sigfau   
   26 Dec 25 04:56:40   
   
   TZUTC: -0800   
   MSGID: 59076.sync_sys@1:103/705 2db4a2cc   
   PID: Synchronet 3.21a-Linux master/48922a15c Dec 17 2025 GCC 12.2.0   
   TID: SBBSecho 3.33-Linux master/3fa76ba1d Dec 21 2025 GCC 12.2.0   
   BBSID: VERT   
   CHRS: UTF-8 4   
   FORMAT: flowed   
   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.a   
   rch64.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/sys   
   /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 app   
   ication)[](url[build.log](/uploads/c280d8dd0279934a90058aa19f1e69a2/build.log)   
      
   [gdb-backtrace.txt](/uploads/8c30c259e1c19ac91cb918c434153284/gd   
   -backtrace.txt)   
      
   [ldd-sbbs.txt](/uploads/acaea3982a92d9ffd2ac2c9d0685c48c/ldd-sbbs.txt)   
      
   [Dockerfile.arm64-debug](/uploads/63f0746fc6530b075aa28bc336e0bf   
   e/Dockerfile.arm64-debug))   
   --- SBBSecho 3.33-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/13 705 105/81 106/201 124/5016 128/187 129/14 153/757   
   SEEN-BY: 153/7715 154/10 30 110 203/0 218/700 221/0 226/30 227/114   
   SEEN-BY: 229/110 112 134 206 317 400 426 428 470 700 705 240/1120   
   SEEN-BY: 240/5832 263/1 266/512 280/464 5003 5006 291/111 292/8125   
   SEEN-BY: 301/1 320/219 322/757 341/66 234 342/200 396/45 423/120 460/58   
   SEEN-BY: 633/267 280 384 410 414 418 420 422 2744 712/848 770/1 902/26   
   SEEN-BY: 5020/400 5075/35   
   PATH: 103/705 280/464 633/280 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca