WeMeet on RISCV Unhandler signal caught, SIGABRT on libstdc++.so.6

[zqb-all]

I noticed in Issue 1280 and some search engine results that wemeet can successfully run on RISC-V, but I encountered errors when I tried it. Are there any special configurations needed?

Error log:

[BOX64] Using emulated /mnt/nvme/wemeet/opt/wemeet/bin/modules/misc/libmisc_module.so
[BOX64] 1012807|Warning, calling Signal 11 function handler SIG_DFL
[BOX64] Unhandled signal caught, aborting
[BOX64] NativeBT: /usr/local/bin/box64() [0x34826138]
[BOX64] NativeBT: /usr/local/bin/box64() [0x3485b768]
[BOX64] NativeBT: linux-vdso.so.1(__vdso_rt_sigreturn+0) [0x3fb4848620]
[BOX64] NativeBT: /usr/lib/riscv64-linux-gnu/libc.so.6(+0x7a08a) [0x3fb471c08a]
[BOX64] NativeBT: /usr/lib/riscv64-linux-gnu/libc.so.6(gsignal+0x18) [0x3fb46dc59c]
[BOX64] NativeBT: /usr/lib/riscv64-linux-gnu/libc.so.6(abort+0x1e) [0x3fb46c984e]
[BOX64] NativeBT: /usr/local/bin/box64() [0x34859b4e]
[BOX64] NativeBT: /usr/local/bin/box64() [0x3485a8ba]
[BOX64] NativeBT: /usr/local/bin/box64() [0x3485b0e0]
[BOX64] NativeBT: /usr/local/bin/box64() [0x348262fe]
[BOX64] NativeBT: /usr/local/bin/box64() [0x3482667c]
[BOX64] NativeBT: /usr/local/bin/box64() [0x34ee4a8e]
[BOX64] NativeBT: /usr/local/bin/box64() [0x34837a04]
[BOX64] NativeBT: /usr/local/bin/box64() [0x3485ea4c]
[BOX64] NativeBT: /usr/lib/riscv64-linux-gnu/libc.so.6(+0x7855a) [0x3fb471a55a]
[BOX64] NativeBT: /usr/lib/riscv64-linux-gnu/libc.so.6(+0xcecd4) [0x3fb4770cd4]
[BOX64] EmulatedBT: box64(/usr/lib/box64-x86_64-linux-gnu/libstdc++.so.6+b9920) [0x3f010b9920]
[BOX64] 1012807|SIGABRT @0x3fb471c08a (???(/usr/lib/riscv64-linux-gnu/libc.so.6+0x7a08a)) (x64pc=0x3f010b9920/"box64//usr/lib/box64-x86_64-linux-gnu/libstdc++.so.6 + 0xb9920", rsp=0x3f42ffb938, stack=0x3f42800000:0x3f43000000 own=0x3f42800000 fp=0x3f42ffc2f0), for accessing 0x3e8000f6d80 (code=-6/prot=0), db=(nil)((nil):(nil)/(nil):(nil)/???:clean, hash:0/0) handler=(nil)
RSP-0x20:0x0000003f40063003 RSP-0x18:0x0000003f42ffb940 RSP-0x10:0x0000003eec05bb60 RSP-0x08:0x0000003f42ffbda8
RSP+0x00:0x0000003f42ffbda8 RSP+0x08:0x0000003f42ffb960 RSP+0x10:0x0000003eec05bb60 RSP+0x18:0x0000000000000002
RAX:0x0666666666666666 RCX:0x0000000000000001 RDX:0x0000000000000001 RBX:0x0000000000000000
RSP:0x0000003f42ffb938 RBP:0x0000003f42ffc2f0 RSI:0x0000000000000001 RDI:0x0000000000000028
 R8:0x00000000000002eb  R9:0x0000003eec16bdd8 R10:0x00000000000005e0 R11:0x0000003f42ffeb88
R12:0x0000000000000000 R13:0x0000000000000000 R14:0x0000000000000000 R15:0x0000000000000000 ES:0x002b CS:0x0033 SS:0x002b DS:0x002b FS:0x0000 GS:0x0000 FSBASE=0x3eec0108e0 GSBASE=(nil)

full log:

wemeet_riscv_20260212.txt

[ptitSeb]

maybe wemeet has been updated and is now crashing? I have not tried on my side yet. There is nothing significant in the log. Just a segfault on default handler (that lead to the abort you copy/paste, but the issue is the segfault, the abort is just a consequence).

[zqb-all]

libwemeet_base.so implements a custom coroutine library using co_setcontext and co_jump_to_link. While co_jump_to_link contains a code path that calls exit(1), this path is never reached under interpreter mode. However, when running under dynarec, this path gets triggered, causing the process to be killed.
A workaround patch is available at #3571, though a more fundamental fix requires further analysis

[ptitSeb]

If the coroutine code have some kind of preemptive enhancement, like with Go, then the issue might be more profound, with signal interupting code in "the wrong" position and using siglongjmp to restore code/stack. I have some plans around this, but it's not very high priority for now, and is quite tricky anyway!

[zqb-all]

Thanks! I'll also take some time to look into the coroutine handling. If there's any progress, I'll open a separate issue or PR.

[zqb-all]

After working around the coroutine issue discussed above, we can see the WeMeet main interface, but further attempts to log in will encounter additional issues.
The workaround PR for this is #3574 (I noticed that steam also sets this flag, so I think perhaps WeMeet could use this as a workaround before the root cause is resolved).
Of course, ultimately we should identify the root cause and remove this flag.

The DIFF:

 [BOX64] Using native(wrapped) libasound.so.2
[BOX64] ignoring prctl(PR_SET_SECCOMP, ...)
libpng warning: tRNS: invalid with alpha channel
[BOX64] Warning, difference between x64 Interpreter and Dynarec in 0x3f02c7aeb8(66 0f 38 35 c0 48 b8 41)
[BOX64] ------------------------------------------------
[BOX64] DIFF: Dynarec |  Interpreter
[BOX64] ------------------------------------------------
[BOX64] XMM[00]: 0000000000000000-000000005b66d7e1 | 000000006f5600b6-000000004fb2d7e1
[BOX64] 0001|Warning, calling Signal 4 function handler SIG_DFL
[BOX64] Unhandled signal caught, aborting
[BOX64] EmulatedBT: /mnt/nvme/wemeet/opt/wemeet/bin/../lib/libQt5WebEngineCore.so.5+3fbdc50 [0x3f05fbdc50]

[zqb-all]

Just for the record, noting it here as well. There was initially another DIFF during login, which has already been fixed by #3569

[BOX64] Warning, difference between x64 Interpreter and Dynarec in 0x3f04235a0d(7f 0c 49 8b 8d 50 01 00)
[BOX64] ------------------------------------------------
[BOX64] DIFF: Dynarec |  Interpreter
[BOX64] ------------------------------------------------
[BOX64] RIP: 0000003f04235a0f | 0000003f04235a1bh

[ptitSeb]

On RISCV, PCLMULQDQ is disable on Steam for speed reason. It does work fine with it, just the download goes slower because of the complexity to emulate this operation on RISCV.
The Opcode should work, it's not supposed to SEGFAULT or SIGILL, that's an issue that should be solved, not workarounded if possible.

[zqb-all]

not workarounded if possible.

Agreed, I'll try to fix it first.

[zqb-all]

With #3576, wemeet no longer triggers exit(1) for now, meaning it can launch without #3571 for the time being.
I think proper handling of exit in coroutines is still meaningful, as it would help us better handle exit calls when running into other similar issues in the future.

[zqb-all]

Here’s a summary of the findings so far. With #3571 （or #3576 ） applied, we can see the initial interface of wemeet, but the QR code fails to display when attempting to log in. Further applying #3616 allows scanning the QR code to log in, but a crash occurs when entering the settings interface. With #3615 additionally applied, the settings interface can be opened normally.
However, whether these PRs are reasonable solutions still requires further consideration.