• SEGV on aarch64

    From deon@1:103/705 to Digital Man on Tue Jan 20 23:41:02 2026
    Hi DM,

    I'm running synchronet on a CM5 under proxmox (its a LXC container), and I was looking to move it to a VM (QEMU).

    When I created the VM and started sbbs, it SEGVs. (My sbbs was build a month or two ago...)

    So I build a debug version with code (as of today) - and it still SEGVs, but now I have a backtrace.

    Any ideas? The host is alpine linux, but the docker container is debian bullseye.

    #0 0x0000fff0f23b8670 in JSObject::getClass (this=0x7ff0d1004100) at jsobj.h:427
    #1 0x0000fff0f23b92e8 in JSObject::isFunction (this=0x7ff0d1004100) at jsfun.h:312
    #2 0x0000fff0f248aa94 in js::IsFunctionObject (v=...) at jsfun.h:342
    #3 js::FindClassPrototype (cx=0xfff0c80193e0, scopeobj=0xfff0d1003048, protoKey=JSProto_Function, protop=0xfff0d27f6e70, clasp=0xfff0f283f1e0 <js_FunctionClass>) at jsobj.cpp:6168
    #4 0x0000fff0f248acf8 in js_GetClassPrototype (cx=0xfff0c80193e0, scopeobj=0xfff0d1003048, protoKey=JSProto_Function, protop=0xfff0d27f6e70, clasp=0xfff0f283f1e0 <js_FunctionClass>)
    at jsobj.cpp:6212
    #5 0x0000fff0f2426190 in js::FindProto (proto=0xfff0d27f6e70, parent=0xfff0d1004080, clasp=0xfff0f283f1e0 <js_FunctionClass>, cx=0xfff0c80193e0) at jsobjinlines.h:1053
    #6 js::detail::NewObject<false, true> (kind=js::gc::FINALIZE_OBJECT2, parent=0xfff0d1004080, proto=0x0, clasp=0xfff0f283f1e0 <js_FunctionClass>, cx=0xfff0c80193e0)
    at jsobjinlines.h:1070
    #7 js::NewFunction (parent=0xfff0d1004080, cx=0xfff0c80193e0) at jsobjinlines.h:1114

    ...

    #20 0x0000fff0f22ec3a8 in event_thread (arg=0xfff0e00764f0) at main.cpp:2888 #21 0x0000fff0f1f84648 in start_thread (arg=0xfff0d27fbac0) at pthread_create.c:477
    #22 0x0000fff0f1edac9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78


    ...ëîåï

    ---
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Jan 20 13:47:00 2026
    Re: SEGV on aarch64
    By: deon to Digital Man on Tue Jan 20 2026 11:41 pm

    Hi DM,

    I'm running synchronet on a CM5 under proxmox (its a LXC container), and I was looking to move it to a VM (QEMU).

    When I created the VM and started sbbs, it SEGVs. (My sbbs was build a month or two ago...)

    So I build a debug version with code (as of today) - and it still SEGVs, but now I have a backtrace.

    Any ideas? The host is alpine linux, but the docker container is debian bullseye.

    #0 0x0000fff0f23b8670 in JSObject::getClass (this=0x7ff0d1004100) at jsobj.h:427
    #1 0x0000fff0f23b92e8 in JSObject::isFunction (this=0x7ff0d1004100) at jsfun.h:312
    #2 0x0000fff0f248aa94 in js::IsFunctionObject (v=...) at jsfun.h:342
    #3 js::FindClassPrototype (cx=0xfff0c80193e0, scopeobj=0xfff0d1003048, protoKey=JSProto_Function, protop=0xfff0d27f6e70, clasp=0xfff0f283f1e0 <js_FunctionClass>) at jsobj.cpp:6168
    #4 0x0000fff0f248acf8 in js_GetClassPrototype (cx=0xfff0c80193e0, scopeobj=0xfff0d1003048, protoKey=JSProto_Function, protop=0xfff0d27f6e70, clasp=0xfff0f283f1e0 <js_FunctionClass>)
    at jsobj.cpp:6212
    #5 0x0000fff0f2426190 in js::FindProto (proto=0xfff0d27f6e70, parent=0xfff0d1004080, clasp=0xfff0f283f1e0 <js_FunctionClass>, cx=0xfff0c80193e0) at jsobjinlines.h:1053
    #6 js::detail::NewObject<false, true> (kind=js::gc::FINALIZE_OBJECT2, parent=0xfff0d1004080, proto=0x0, clasp=0xfff0f283f1e0 <js_FunctionClass>, cx=0xfff0c80193e0)
    at jsobjinlines.h:1070
    #7 js::NewFunction (parent=0xfff0d1004080, cx=0xfff0c80193e0) at jsobjinlines.h:1114

    ...

    #20 0x0000fff0f22ec3a8 in event_thread (arg=0xfff0e00764f0) at main.cpp:2888 #21 0x0000fff0f1f84648 in start_thread (arg=0xfff0d27fbac0) at pthread_create.c:477
    #22 0x0000fff0f1edac9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

    Sounds like maybe the same issue reported here: https://gitlab.synchro.net/main/sbbs/-/issues/685
    --
    digital man (rob)

    Rush quote #35:
    Static on your frequency, electrical storm in your veins
    Norco, CA WX: 79.8øF, 17.0% humidity, 0 mph NW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.34-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Wed Jan 21 20:09:00 2026
    Re: SEGV on aarch64
    By: Digital Man to deon on Tue Jan 20 2026 01:47 pm

    Howdy,

    Sounds like maybe the same issue reported here: https://gitlab.synchro.net/main/sbbs/-/issues/685

    Hmm... OK?

    I started sbbs (vanilla setup with all build defaults) with NO_EVENTS set, and it didnt segv. (Not sure what that implies).

    I tried the setarch thing and no different (it segfaulted). (I thought deuce's patch meant that setarch was no longer required anyway?)

    I even started the container privilieged, and was running sbbs as root, so file permissions shouldnt have been a factor.

    I ran the same (albeit older) docker image on the same host under lxc and it runs fine.

    Thus the differences are the alpine kernel (in qemu) vs the pve (debian) kernel (that would be used by lxc).

    Or lxc vs qemu.

    Open to ideas to try, otherwise it sounds like a nogo...


    ...ëîåï

    ---
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Wed Jan 21 01:21:04 2026
    Re: SEGV on aarch64
    By: deon to Digital Man on Wed Jan 21 2026 08:09 pm

    Re: SEGV on aarch64
    By: Digital Man to deon on Tue Jan 20 2026 01:47 pm

    Howdy,

    Sounds like maybe the same issue reported here: https://gitlab.synchro.net/main/sbbs/-/issues/685

    Hmm... OK?

    I started sbbs (vanilla setup with all build defaults) with NO_EVENTS set, and it didnt segv. (Not sure what that implies).

    I tried the setarch thing and no different (it segfaulted). (I thought deuce's patch meant that setarch was no longer required anyway?)

    I even started the container privilieged, and was running sbbs as root, so file permissions shouldnt have been a factor.

    I ran the same (albeit older) docker image on the same host under lxc and it runs fine.

    Thus the differences are the alpine kernel (in qemu) vs the pve (debian) kernel (that would be used by lxc).

    Or lxc vs qemu.

    Open to ideas to try, otherwise it sounds like a nogo...

    I encourage you to have the conversation there in the gitlab issue thread. Deuce may not see your reply here.
    --
    digital man (rob)

    Steven Wright quote #31:
    The sooner you fall behind, the more time you'll have to catch up.
    Norco, CA WX: 56.7øF, 52.0% humidity, 2 mph NW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.35-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)