Is this a situation where two libc's are being loaded into the address space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
We solved that for most programs. Something special about python? Stuart Henderson <s...@spacehopper.org> wrote: > On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote: > > gajim is reporting a msyscall error on launch since today's snapshot. > > This is likely to be fixed by updating to packages built against the new > libc version when they're available. > > > OpenBSD 7.5 (GENERIC.MP) #46: Fri Mar 1 19:36:05 MST 2024 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > 99921 python3.10 CALL munmap(0xfbdb9aea778,0x6e8) > > 99921 python3.10 RET munmap 0 > > 99921 python3.10 CALL > > pinsyscalls(0xfbdbb503000,0xa8000,0xfbdb71b7000,0x14b) > > 99921 python3.10 RET pinsyscalls -1 errno 1 Operation not permitted > > 99921 python3.10 CALL msyscall(0xfbdbb503000,0xa8000) > > 99921 python3.10 RET msyscall -1 errno 1 Operation not permitted > > 99921 python3.10 CALL write(2,0xfbe2e754020,0x21) > > 99921 python3.10 GIO fd 2 wrote 33 bytes > > "msyscall fbdbb503000 a8000 error > > " > > 99921 python3.10 RET write 33/0x21 > > 99921 python3.10 CALL close(9) > > 99921 python3.10 RET close 0 > > 99921 python3.10 CALL > > mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > > 99921 python3.10 RET mmap 17308774350848/0xfbe0358c000 > > 99921 python3.10 CALL issetugid() > > 99921 python3.10 PSIG SIGSEGV SIG_DFL code=SEGV_ACCERR addr=0xfbdbb54cfcb > > trapno=0 > > > > I can share the full ktrace. egdb only shows a ?? traceback. Should I > > try building the debug package for it? Last time I tried it with Gajim > > it didn't provide much information as lot of things happened in > > libraries. > > > > Lucas > > >
