On 2024/03/02 14:46, Theo de Raadt wrote: > 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.
It seems the most likely cause. Console output from running with LD_DEBUG set in the environment would probably confirm (and would be more useful than kdump). I can't replicate it here on a system with new libc (I only tried starting gajim and poking in the UI, not connecting to any servers). > We solved that for most programs. Something special about python? Not sure. I assume it's because external Python modules are dlopen()'d and perhaps there could be some edge case in the "only load one libc" code in ld.so. I'm a bit surprised why a mixture of libs would happen there at all (unless something had been rebuilt locally) but don't see another reason to hit the msyscall error. > 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 > > > > > >
