Re: Gajim msyscall error

[Theo de Raadt]

Mark Kettenis  wrote:

> > From: "Theo de Raadt" 
> > Date: Sun, 03 Mar 2024 08:20:33 -0700
> > 
> > It almost feels as if libc.so equivelancy should be closer to
> > _dl_find_shlib(),
> > 
> > (in particular, meaning searchpath[0] in _dl_find_shlib() coming
> > from lpath in _dl_load_shlib()
> > 
> > Is testing for this in loader.c not the right place, and that
> > code should be moved to a deeper place, reached by more variations?
> 
> Yes, the diff below would make more sense.  Anyway, probably something
> to do after the next release?
> 
> > The thing that would break is if someone dlopen() of
> > "libc.so.not-a-system-library", and that is a real .so but not a real
> > full libc; imagine it just contains 1 stub function which isn't a
> > system call.  it would now fail to load that stub function.  So maybe
> > it is better if we force the applications to request "libc.so".

No, I'm scared because this diff still converts "libc.so.tinysomething"
with reference to the preloaded "libc.so".

I think stuart's diff to python is safer.

Re: Gajim msyscall error

[Mark Kettenis]

> From: "Theo de Raadt" 
> Date: Sun, 03 Mar 2024 08:20:33 -0700
> 
> It almost feels as if libc.so equivelancy should be closer to
> _dl_find_shlib(),
> 
> (in particular, meaning searchpath[0] in _dl_find_shlib() coming
> from lpath in _dl_load_shlib()
> 
> Is testing for this in loader.c not the right place, and that
> code should be moved to a deeper place, reached by more variations?

Yes, the diff below would make more sense.  Anyway, probably something
to do after the next release?

> The thing that would break is if someone dlopen() of
> "libc.so.not-a-system-library", and that is a real .so but not a real
> full libc; imagine it just contains 1 stub function which isn't a
> system call.  it would now fail to load that stub function.  So maybe
> it is better if we force the applications to request "libc.so".

Index: libexec/ld.so/library_subr.c
===
RCS file: /cvs/src/libexec/ld.so/library_subr.c,v
retrieving revision 1.55
diff -u -p -r1.55 library_subr.c
--- libexec/ld.so/library_subr.c27 Apr 2023 12:27:56 -  1.55
+++ libexec/ld.so/library_subr.c3 Mar 2024 16:44:33 -
@@ -321,6 +321,11 @@ _dl_load_shlib(const char *libname, elf_
try_any_minor = 0;
ignore_hints = 0;
 
+   if (_dl_strncmp(libname, "libc.so.", 8) == 0) {
+   if (_dl_libcname)
+   libname = _dl_libcname;
+   }
+
if (_dl_strchr(libname, '/')) {
char *paths[2];
char *lpath, *lname;
Index: libexec/ld.so/loader.c
===
RCS file: /cvs/src/libexec/ld.so/loader.c,v
retrieving revision 1.223
diff -u -p -r1.223 loader.c
--- libexec/ld.so/loader.c  22 Jan 2024 02:08:31 -  1.223
+++ libexec/ld.so/loader.c  3 Mar 2024 16:44:33 -
@@ -406,10 +406,6 @@ _dl_load_dep_libs(elf_object_t *object, 
liblist[randomlist[loop]].dynp->d_un.d_val;
DL_DEB(("loading: %s required by %s\n", libname,
dynobj->load_name));
-   if (_dl_strncmp(libname, "libc.so.", 8) == 0) {
-   if (_dl_libcname)
-   libname = _dl_libcname;
-   }
depobj = _dl_load_shlib(libname, dynobj,
OBJTYPE_LIB, depflags, nodelete);
if (depobj == 0) {
Index: libexec/ld.so/resolve.h
===
RCS file: /cvs/src/libexec/ld.so/resolve.h,v
retrieving revision 1.107
diff -u -p -r1.107 resolve.h
--- libexec/ld.so/resolve.h 16 Jan 2024 19:07:31 -  1.107
+++ libexec/ld.so/resolve.h 3 Mar 2024 16:44:33 -
@@ -376,6 +376,7 @@ extern char **_dl_libpath;
 extern int _dl_bindnow;
 extern int _dl_traceld;
 extern int _dl_debug;
+extern const char *_dl_libcname;
 
 extern char *_dl_preload;
 extern char *_dl_tracefmt1;

Re: Gajim msyscall error

[Theo de Raadt]

Stuart Henderson  wrote:

> +allow dlopen() to search for libc rather than parsing ldconfig -r to
> +decide on a version number.
> +
> +(would this make sense for all libraries? I'm not sure exactly what
> +parameters this might be called with, whether it's just a bare name or
> +could have a path/version in it).

I wonder how many places we have the same problem with other libraries.

libc.so is just being strict and failing hard.

Other libraries may fail in extremely subtle ways.  One caller changes
global state in libfoo.so.A.A's mapping, another caller uses libfoo.so.X.X's
mapping without having the initialized state.

Why would we ever want two libfoo.so.?.? mapped into memory?

I suspect the hard-to-diagnose bugs are more dangerous than the capability
to do so.

Re: Gajim msyscall error

[Stuart Henderson]

On 2024/03/03 15:21, Stuart Henderson wrote:
> On 2024/03/03 07:59, Theo de Raadt wrote:
> > Does it work if this is modified to just ask for "libc.so"?
> 
> Yes. Conservative approach just doing this for libc:

oh, we need to update the installed list-of-changes file too,
and diff updated to include 3.11 as well. I don't think I'll bother
with patching the legacy versions.

any OKs?

Index: 3.10/Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- 3.10/Makefile   14 Nov 2023 12:33:56 -  1.37
+++ 3.10/Makefile   3 Mar 2024 15:24:58 -
@@ -4,7 +4,7 @@
 # Python itself.
 
 FULL_VERSION = 3.10.13
-REVISION = 0
+REVISION = 1
 SHARED_LIBS =  python3.10 0.0
 VERSION_SPEC = >=3.10,<3.11
 PORTROACH =limit:^3\.10
Index: 3.10/files/CHANGES.OpenBSD
===
RCS file: /cvs/ports/lang/python/3.10/files/CHANGES.OpenBSD,v
retrieving revision 1.13
diff -u -p -r1.13 CHANGES.OpenBSD
--- 3.10/files/CHANGES.OpenBSD  24 Apr 2023 11:15:43 -  1.13
+++ 3.10/files/CHANGES.OpenBSD  3 Mar 2024 15:24:58 -
@@ -19,5 +19,9 @@ compiler as passed to ports builds is /u
 6.  Use closefrom(2) instead of looping through all the file descriptors
 and calling close(2) on them.
 
+7.  ctypes' find_library is modified to pass "libc.so" to dlopen() rather
+than attempting to resolve a version number by parsing ldconfig -r output,
+which results in loading an incorrect version in some cases.
+
 These changes are available in the OpenBSD CVS repository
  in ports/lang/python/3.10.
Index: 3.10/patches/patch-Lib_ctypes_util_py
===
RCS file: 3.10/patches/patch-Lib_ctypes_util_py
diff -N 3.10/patches/patch-Lib_ctypes_util_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ 3.10/patches/patch-Lib_ctypes_util_py   3 Mar 2024 15:24:58 -
@@ -0,0 +1,20 @@
+allow dlopen() to search for libc rather than parsing ldconfig -r to
+decide on a version number.
+
+(would this make sense for all libraries? I'm not sure exactly what
+parameters this might be called with, whether it's just a bare name or
+could have a path/version in it).
+
+Index: Lib/ctypes/util.py
+--- Lib/ctypes/util.py.orig
 Lib/ctypes/util.py
+@@ -204,6 +204,9 @@ elif os.name == "posix":
+ return nums or [sys.maxsize]
+ 
+ def find_library(name):
++if sys.platform.startswith("openbsd") and name == "c":
++return "libc.so"
++
+ ename = re.escape(name)
+ expr = r':-l%s\.\S+ => \S*/(lib%s\.\S+)' % (ename, ename)
+ expr = os.fsencode(expr)
Index: 3.11/Makefile
===
RCS file: /cvs/ports/lang/python/3.11/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- 3.11/Makefile   12 Feb 2024 00:53:52 -  1.14
+++ 3.11/Makefile   3 Mar 2024 15:24:58 -
@@ -4,6 +4,7 @@
 # Python itself.
 
 FULL_VERSION = 3.11.8
+REVISION = 0
 SHARED_LIBS =  python3.11 0.0
 VERSION_SPEC = >=3.11,<3.12
 PORTROACH =limit:^3\.11
Index: 3.11/files/CHANGES.OpenBSD
===
RCS file: /cvs/ports/lang/python/3.11/files/CHANGES.OpenBSD,v
retrieving revision 1.4
diff -u -p -r1.4 CHANGES.OpenBSD
--- 3.11/files/CHANGES.OpenBSD  24 Apr 2023 11:18:57 -  1.4
+++ 3.11/files/CHANGES.OpenBSD  3 Mar 2024 15:24:58 -
@@ -19,5 +19,9 @@ compiler as passed to ports builds is /u
 6.  Use closefrom(2) instead of looping through all the file descriptors
 and calling close(2) on them.
 
+7.  ctypes' find_library is modified to pass "libc.so" to dlopen() rather
+than attempting to resolve a version number by parsing ldconfig -r output,
+which results in loading an incorrect version in some cases.
+
 These changes are available in the OpenBSD CVS repository
  in ports/lang/python/3.11.
Index: 3.11/patches/patch-Lib_ctypes_util_py
===
RCS file: 3.11/patches/patch-Lib_ctypes_util_py
diff -N 3.11/patches/patch-Lib_ctypes_util_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ 3.11/patches/patch-Lib_ctypes_util_py   3 Mar 2024 15:24:58 -
@@ -0,0 +1,20 @@
+allow dlopen() to search for libc rather than parsing ldconfig -r to
+decide on a version number.
+
+(would this make sense for all libraries? I'm not sure exactly what
+parameters this might be called with, whether it's just a bare name or
+could have a path/version in it).
+
+Index: Lib/ctypes/util.py
+--- Lib/ctypes/util.py.orig
 Lib/ctypes/util.py
+@@ -207,6 +207,9 @@ elif os.name == "posix":
+ return nums or 

Re: Gajim msyscall error

[Stuart Henderson]

On 2024/03/03 07:59, Theo de Raadt wrote:
> Does it work if this is modified to just ask for "libc.so"?

Yes. Conservative approach just doing this for libc:

Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile14 Nov 2023 12:33:56 -  1.37
+++ Makefile3 Mar 2024 15:20:11 -
@@ -4,7 +4,7 @@
 # Python itself.
 
 FULL_VERSION = 3.10.13
-REVISION = 0
+REVISION = 1
 SHARED_LIBS =  python3.10 0.0
 VERSION_SPEC = >=3.10,<3.11
 PORTROACH =limit:^3\.10
Index: patches/patch-Lib_ctypes_util_py
===
RCS file: patches/patch-Lib_ctypes_util_py
diff -N patches/patch-Lib_ctypes_util_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-Lib_ctypes_util_py3 Mar 2024 15:20:11 -
@@ -0,0 +1,20 @@
+allow dlopen() to search for libc rather than parsing ldconfig -r to
+decide on a version number.
+
+(would this make sense for all libraries? I'm not sure exactly what
+parameters this might be called with, whether it's just a bare name or
+could have a path/version in it).
+
+Index: Lib/ctypes/util.py
+--- Lib/ctypes/util.py.orig
 Lib/ctypes/util.py
+@@ -204,6 +204,9 @@ elif os.name == "posix":
+ return nums or [sys.maxsize]
+ 
+ def find_library(name):
++if sys.platform.startswith("openbsd") and name == "c":
++return "libc.so"
++
+ ename = re.escape(name)
+ expr = r':-l%s\.\S+ => \S*/(lib%s\.\S+)' % (ename, ename)
+ expr = os.fsencode(expr)

Re: Gajim msyscall error

[Theo de Raadt]

It almost feels as if libc.so equivelancy should be closer to
_dl_find_shlib(),

(in particular, meaning searchpath[0] in _dl_find_shlib() coming
from lpath in _dl_load_shlib()

Is testing for this in loader.c not the right place, and that
code should be moved to a deeper place, reached by more variations?

The thing that would break is if someone dlopen() of
"libc.so.not-a-system-library", and that is a real .so but not a real
full libc; imagine it just contains 1 stub function which isn't a
system call.  it would now fail to load that stub function.  So maybe
it is better if we force the applications to request "libc.so".

Re: Gajim msyscall error

[Mark Kettenis]

> Date: Sun, 3 Mar 2024 14:35:09 +
> From: Stuart Henderson 
> 
> On 2024/03/03 14:29, Stuart Henderson wrote:
> > On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > > On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > > > 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).
> > > 
> > > See end of this mail.
> > > 
> > > > 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).
> > > 
> > > ftr, I don't even get to the UI.
> > 
> > Ah, I can replicate if I ldconfig -R.
> > 
> > > > 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.
> > > 
> > > Nothing has been locally rebuilt.
> > > 
> > > LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
> > > attempted to load.
> > 
> > 
> > > dlsym: gtk_get_minor_version in /usr/local/lib/libgtk-3.so.2201.0: 
> > > 0x17287b9f300
> > > dlsym: gtk_get_micro_version in /usr/local/lib/libgtk-3.so.2201.0: 
> > > 0x17287b9f330
> > > dlsym: pango_version_string in /usr/local/lib/libpango-1.0.so.3801.4: 
> > > 0x172ed038d60
> > > dlopen: loading: libc.so.99.0
> > > msyscall 1732a806000 a8000 error
> > 
> > Coming from ...
> > 
> > Breakpoint 1.1, dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at 
> > /usr/src/libexec/ld.so/dlfcn.c:64
> > 64  if (flags & ~OK_FLAGS) {
> > (gdb) bt
> > #0  dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at 
> > /usr/src/libexec/ld.so/dlfcn.c:64
> > #1  0x098b93dc7d01 in py_dl_open () from 
> > /usr/local/lib/python3.10/lib-dynload/_ctypes.cpython-310.so
> > #2  0x098bb0dc1bc1 in cfunction_call () from 
> > /usr/local/lib/libpython3.10.so.0.0
> > #3  0x098bb0d6a132 in _PyObject_MakeTpCall () from 
> > /usr/local/lib/libpython3.10.so.0.0
> > 
> > 
> > so something is doing dlopen("libc.so.99.0", RTLD_NOW) ...
> > 
> > (gdb) py-bt
> > Traceback (most recent call first):
> >   
> >   File "/usr/local/lib/python3.10/ctypes/__init__.py", line 374, in __init__
> > self._handle = _dlopen(self._name, mode)
> >   File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 147, 
> > in _set_proc_title
> > libc = CDLL(find_library('c'))
> >   File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 168, 
> > in run
> > _set_proc_title()
> >   File "/usr/local/bin/gajim", line 8, in 
> > sys.exit(run())
> > 
> > aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> > (without a specific version number). ld.so is picking the latest and
> > loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> > error.
> 
> oh, it's not ld.so which is picking the latest version, it's python's
> ctypes code, which parses the output of "ldconfig -r" to decide.
> 
> I don't think there's anything we can sanely do in ld.so to work
> around this.

We could do something like this.  Still not 100% foolproof though.

Index: libexec/ld.so/dlfcn.c
===
RCS file: /cvs/src/libexec/ld.so/dlfcn.c,v
retrieving revision 1.117
diff -u -p -r1.117 dlfcn.c
--- libexec/ld.so/dlfcn.c   22 Jan 2024 02:08:31 -  1.117
+++ libexec/ld.so/dlfcn.c   3 Mar 2024 15:10:22 -
@@ -68,6 +68,10 @@ dlopen(const char *libname, int flags)
 
if (libname == NULL)
return RTLD_DEFAULT;
+   if (_dl_strncmp(libname, "libc.so.", 8) == 0) {
+   if (_dl_libcname)
+   libname = _dl_libcname;
+   }
 
if ((flags & RTLD_TRACE) == RTLD_TRACE) {
_dl_traceld = 1;
Index: libexec/ld.so/resolve.h
===
RCS file: /cvs/src/libexec/ld.so/resolve.h,v
retrieving revision 1.107
diff -u -p -r1.107 resolve.h
--- libexec/ld.so/resolve.h 16 Jan 2024 19:07:31 -  1.107
+++ libexec/ld.so/resolve.h 3 Mar 2024 15:10:22 -
@@ -376,6 +376,7 @@ extern char **_dl_libpath;
 extern int _dl_bindnow;
 extern int _dl_traceld;
 extern int _dl_debug;
+extern const char *_dl_libcname;
 
 extern char *_dl_preload;
 extern char *_dl_tracefmt1;

Re: Gajim msyscall error

[Theo de Raadt]

Stuart Henderson  wrote:

> > aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> > (without a specific version number). ld.so is picking the latest and
> > loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> > error.
> 
> oh, it's not ld.so which is picking the latest version, it's python's
> ctypes code, which parses the output of "ldconfig -r" to decide.

That's just so ridiculous.  On all other operating systems that is not
neccessary, because they don't do versioning, so they only have one library.
That approach is wrong.

Does it work if this is modified to just ask for "libc.so"?

> I don't think there's anything we can sanely do in ld.so to work
> around this.

No, actually maybe we can.  It just isn't what the current ld.so diff was
trying to do.  It was more conservative.  It could perform more aggressive
remapping, but then we need a long test cycle to ensure there's no bad
effects.

Re: Gajim msyscall error

[Theo de Raadt]

> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> (without a specific version number). ld.so is picking the latest and
> loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> error.

Time to explain the msyscall thing a bit.

msyscall(2) will go away after release, since pinsyscalls(2) has
replaced it.  msyscall(2) was the first mechanism for "range of memory
where system calls occur from", pinsyscalls(2) is the new mechanism with
"precise entry points for system calls".

The failure to msyscall(2) prints a warning message in ld.so.  But the
failure of pinsyscalls(2) in ld.so does not print a warning message.
However the pinsyscalls(2) failure is visible in the ktrace.  Both of
them fail.

The reality is if a system call is called from that 2nd libc.so library
mapping, the process will exit hard with SIGABRT.  It isn't the msyscall message
that matters here, but that you simply can't have another region
containing the ability to call system calls.


ld.so was modified to coerce additional "libc.so" mapping requests
into reusing the first libc.so choice made by ld.so.

The ld.so/loader.c logic has not chosen to do that in this case, and I
can't see why that didn't happen.  There's two bugs, really.

1. the application chose to load another library version, because it is
   compiled or discovered somehow.  We cannot find and fix all those cases
   because programs do really weird things to get those library names.

2. ld.so must do the job of coercing all "libc.so*" requests to the original
   libc.so choice, and the ld.so diff isn't sufficient for this case.

We can't fix 1, so #2 is what kettenis has been trying to do.

Re: Gajim msyscall error

[Stuart Henderson]

On 2024/03/03 14:29, Stuart Henderson wrote:
> On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > > 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).
> > 
> > See end of this mail.
> > 
> > > 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).
> > 
> > ftr, I don't even get to the UI.
> 
> Ah, I can replicate if I ldconfig -R.
> 
> > > 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.
> > 
> > Nothing has been locally rebuilt.
> > 
> > LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
> > attempted to load.
> 
> 
> > dlsym: gtk_get_minor_version in /usr/local/lib/libgtk-3.so.2201.0: 
> > 0x17287b9f300
> > dlsym: gtk_get_micro_version in /usr/local/lib/libgtk-3.so.2201.0: 
> > 0x17287b9f330
> > dlsym: pango_version_string in /usr/local/lib/libpango-1.0.so.3801.4: 
> > 0x172ed038d60
> > dlopen: loading: libc.so.99.0
> > msyscall 1732a806000 a8000 error
> 
> Coming from ...
> 
> Breakpoint 1.1, dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at 
> /usr/src/libexec/ld.so/dlfcn.c:64
> 64if (flags & ~OK_FLAGS) {
> (gdb) bt
> #0  dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at 
> /usr/src/libexec/ld.so/dlfcn.c:64
> #1  0x098b93dc7d01 in py_dl_open () from 
> /usr/local/lib/python3.10/lib-dynload/_ctypes.cpython-310.so
> #2  0x098bb0dc1bc1 in cfunction_call () from 
> /usr/local/lib/libpython3.10.so.0.0
> #3  0x098bb0d6a132 in _PyObject_MakeTpCall () from 
> /usr/local/lib/libpython3.10.so.0.0
> 
> 
> so something is doing dlopen("libc.so.99.0", RTLD_NOW) ...
> 
> (gdb) py-bt
> Traceback (most recent call first):
>   
>   File "/usr/local/lib/python3.10/ctypes/__init__.py", line 374, in __init__
> self._handle = _dlopen(self._name, mode)
>   File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 147, in 
> _set_proc_title
> libc = CDLL(find_library('c'))
>   File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 168, in 
> run
> _set_proc_title()
>   File "/usr/local/bin/gajim", line 8, in 
> sys.exit(run())
> 
> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> (without a specific version number). ld.so is picking the latest and
> loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> error.

oh, it's not ld.so which is picking the latest version, it's python's
ctypes code, which parses the output of "ldconfig -r" to decide.

I don't think there's anything we can sanely do in ld.so to work
around this.

Re: Gajim msyscall error

[Stuart Henderson]

On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > 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).
> 
> See end of this mail.
> 
> > 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).
> 
> ftr, I don't even get to the UI.

Ah, I can replicate if I ldconfig -R.

> > 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.
> 
> Nothing has been locally rebuilt.
> 
> LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
> attempted to load.


> dlsym: gtk_get_minor_version in /usr/local/lib/libgtk-3.so.2201.0: 
> 0x17287b9f300
> dlsym: gtk_get_micro_version in /usr/local/lib/libgtk-3.so.2201.0: 
> 0x17287b9f330
> dlsym: pango_version_string in /usr/local/lib/libpango-1.0.so.3801.4: 
> 0x172ed038d60
> dlopen: loading: libc.so.99.0
> msyscall 1732a806000 a8000 error

Coming from ...

Breakpoint 1.1, dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at 
/usr/src/libexec/ld.so/dlfcn.c:64
64  if (flags & ~OK_FLAGS) {
(gdb) bt
#0  dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at 
/usr/src/libexec/ld.so/dlfcn.c:64
#1  0x098b93dc7d01 in py_dl_open () from 
/usr/local/lib/python3.10/lib-dynload/_ctypes.cpython-310.so
#2  0x098bb0dc1bc1 in cfunction_call () from 
/usr/local/lib/libpython3.10.so.0.0
#3  0x098bb0d6a132 in _PyObject_MakeTpCall () from 
/usr/local/lib/libpython3.10.so.0.0


so something is doing dlopen("libc.so.99.0", RTLD_NOW) ...

(gdb) py-bt
Traceback (most recent call first):
  
  File "/usr/local/lib/python3.10/ctypes/__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
  File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 147, in 
_set_proc_title
libc = CDLL(find_library('c'))
  File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 168, in run
_set_proc_title()
  File "/usr/local/bin/gajim", line 8, in 
sys.exit(run())

aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
(without a specific version number). ld.so is picking the latest and
loading it, but libc.so.98.0 was already loaded, so we hit msyscall
error.

If you need to run it now you can workaround in this instance by editing
/usr/local/lib/python3.10/site-packages/gajim/main.py:

144 def _set_proc_title() -> None:
145 sysname = platform.system()
146 if sysname in ('Linux', 'FreeBSD', 'OpenBSD', 'NetBSD'):
147 libc = CDLL(find_library('c'))

e.g. remove OpenBSD from the "if sysname" line.

Re: Gajim msyscall error

[Mark Kettenis]

> Date: Sun, 3 Mar 2024 13:19:36 +
> From: Lucas Gabriel Vuotto 
> 
> On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > 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).
> 
> See end of this mail.
> 
> > 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).
> 
> ftr, I don't even get to the UI.
> 
> > > 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.
> 
> Nothing has been locally rebuilt.
> 
> LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
> attempted to load.

So something is explicitly dlopening libc.so.99.0.  You can't beat stupid...

Do whe have any clue where in the dependency chain this happens?

> ld.so loading: 'python3.10'
> exe load offset:  0x1706abe9000
> objname [/usr/local/bin/python3.10], dynp 0x1706abebc78, objtype 2 lbase 
> 1706abe9000, obase 1706abe9000
>  flags /usr/local/bin/python3.10 = 0x800
> head /usr/local/bin/python3.10
> obj /usr/local/bin/python3.10 has /usr/local/bin/python3.10 as head
> examining: '/usr/local/bin/python3.10'
> loading: libm.so.10.1 required by /usr/local/bin/python3.10
> objname [/usr/lib/libm.so.10.1], dynp 0x172f2b42668, objtype 3 lbase 
> 172f2b13000, obase 172f2b13000
>  flags /usr/lib/libm.so.10.1 = 0x0
> obj /usr/lib/libm.so.10.1 has /usr/local/bin/python3.10 as head
> loading: libpython3.10.so.0.0 required by /usr/local/bin/python3.10
> objname [/usr/local/lib/libpython3.10.so.0.0], dynp 0x1727f4bb248, objtype 3 
> lbase 1727f11d000, obase 1727f11d000
>  flags /usr/local/lib/libpython3.10.so.0.0 = 0x0
> obj /usr/local/lib/libpython3.10.so.0.0 has /usr/local/bin/python3.10 as head
> loading: libintl.so.8.0 required by /usr/local/bin/python3.10
> objname [/usr/local/lib/libintl.so.8.0], dynp 0x1729bbd1478, objtype 3 lbase 
> 1729bbb1000, obase 1729bbb1000
>  flags /usr/local/lib/libintl.so.8.0 = 0x0
> obj /usr/local/lib/libintl.so.8.0 has /usr/local/bin/python3.10 as head
> loading: libpthread.so.27.1 required by /usr/local/bin/python3.10
> objname [/usr/lib/libpthread.so.27.1], dynp 0x1733800eb78, objtype 3 lbase 
> 17338004000, obase 17338004000
>  flags /usr/lib/libpthread.so.27.1 = 0x8
> obj /usr/lib/libpthread.so.27.1 has /usr/local/bin/python3.10 as head
> loading: libutil.so.18.0 required by /usr/local/bin/python3.10
> objname [/usr/lib/libutil.so.18.0], dynp 0x1735d3e7230, objtype 3 lbase 
> 1735d3d1000, obase 1735d3d1000
>  flags /usr/lib/libutil.so.18.0 = 0x0
> obj /usr/lib/libutil.so.18.0 has /usr/local/bin/python3.10 as head
> loading: libc.so.98.0 required by /usr/local/bin/python3.10
> objname [/usr/lib/libc.so.98.0], dynp 0x1733679f5d8, objtype 3 lbase 
> 173366bb000, obase 173366bb000
>  flags /usr/lib/libc.so.98.0 = 0x21
> obj /usr/lib/libc.so.98.0 has /usr/local/bin/python3.10 as head
> linking dep /usr/local/lib/libpython3.10.so.0.0 as child of 
> /usr/local/bin/python3.10
> linking dep /usr/local/lib/libintl.so.8.0 as child of 
> /usr/local/bin/python3.10
> objname /usr/lib/libpthread.so.27.1 is nodelete
> linking dep /usr/lib/libpthread.so.27.1 as child of /usr/local/bin/python3.10
> linking dep /usr/lib/libutil.so.18.0 as child of /usr/local/bin/python3.10
> linking dep /usr/lib/libm.so.10.1 as child of /usr/local/bin/python3.10
> linking dep /usr/lib/libc.so.98.0 as child of /usr/local/bin/python3.10
> examining: '/usr/local/lib/libpython3.10.so.0.0'
> loading: libutil.so.18.0 required by /usr/local/lib/libpython3.10.so.0.0
> loading: libm.so.10.1 required by /usr/local/lib/libpython3.10.so.0.0
> loading: libpthread.so.27.1 required by /usr/local/lib/libpython3.10.so.0.0
> loading: libintl.so.8.0 required by /usr/local/lib/libpython3.10.so.0.0
> linking dep /usr/local/lib/libintl.so.8.0 as child of 
> /usr/local/lib/libpython3.10.so.0.0
> linking dep /usr/lib/libpthread.so.27.1 as child of 
> /usr/local/lib/libpython3.10.so.0.0
> linking dep /usr/lib/libutil.so.18.0 as child of 
> /usr/local/lib/libpython3.10.so.0.0
> linking dep /usr/lib/libm.so.10.1 as child of 
> /usr/local/lib/libpython3.10.so.0.0
> examining: '/usr/local/lib/libintl.so.8.0'
> loading: libiconv.so.7.1 required by /usr/local/lib/libintl.so.8.0
> objname [/usr/local/lib/libiconv.so.7.1], dynp 0x172d4183598, objtype 3 lbase 
> 172d4073000, 

Re: Gajim msyscall error

[Lucas Gabriel Vuotto]

On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> 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).

See end of this mail.

> 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).

ftr, I don't even get to the UI.

> > 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.

Nothing has been locally rebuilt.

LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
attempted to load.


ld.so loading: 'python3.10'
exe load offset:  0x1706abe9000
objname [/usr/local/bin/python3.10], dynp 0x1706abebc78, objtype 2 lbase 
1706abe9000, obase 1706abe9000
 flags /usr/local/bin/python3.10 = 0x800
head /usr/local/bin/python3.10
obj /usr/local/bin/python3.10 has /usr/local/bin/python3.10 as head
examining: '/usr/local/bin/python3.10'
loading: libm.so.10.1 required by /usr/local/bin/python3.10
objname [/usr/lib/libm.so.10.1], dynp 0x172f2b42668, objtype 3 lbase 
172f2b13000, obase 172f2b13000
 flags /usr/lib/libm.so.10.1 = 0x0
obj /usr/lib/libm.so.10.1 has /usr/local/bin/python3.10 as head
loading: libpython3.10.so.0.0 required by /usr/local/bin/python3.10
objname [/usr/local/lib/libpython3.10.so.0.0], dynp 0x1727f4bb248, objtype 3 
lbase 1727f11d000, obase 1727f11d000
 flags /usr/local/lib/libpython3.10.so.0.0 = 0x0
obj /usr/local/lib/libpython3.10.so.0.0 has /usr/local/bin/python3.10 as head
loading: libintl.so.8.0 required by /usr/local/bin/python3.10
objname [/usr/local/lib/libintl.so.8.0], dynp 0x1729bbd1478, objtype 3 lbase 
1729bbb1000, obase 1729bbb1000
 flags /usr/local/lib/libintl.so.8.0 = 0x0
obj /usr/local/lib/libintl.so.8.0 has /usr/local/bin/python3.10 as head
loading: libpthread.so.27.1 required by /usr/local/bin/python3.10
objname [/usr/lib/libpthread.so.27.1], dynp 0x1733800eb78, objtype 3 lbase 
17338004000, obase 17338004000
 flags /usr/lib/libpthread.so.27.1 = 0x8
obj /usr/lib/libpthread.so.27.1 has /usr/local/bin/python3.10 as head
loading: libutil.so.18.0 required by /usr/local/bin/python3.10
objname [/usr/lib/libutil.so.18.0], dynp 0x1735d3e7230, objtype 3 lbase 
1735d3d1000, obase 1735d3d1000
 flags /usr/lib/libutil.so.18.0 = 0x0
obj /usr/lib/libutil.so.18.0 has /usr/local/bin/python3.10 as head
loading: libc.so.98.0 required by /usr/local/bin/python3.10
objname [/usr/lib/libc.so.98.0], dynp 0x1733679f5d8, objtype 3 lbase 
173366bb000, obase 173366bb000
 flags /usr/lib/libc.so.98.0 = 0x21
obj /usr/lib/libc.so.98.0 has /usr/local/bin/python3.10 as head
linking dep /usr/local/lib/libpython3.10.so.0.0 as child of 
/usr/local/bin/python3.10
linking dep /usr/local/lib/libintl.so.8.0 as child of /usr/local/bin/python3.10
objname /usr/lib/libpthread.so.27.1 is nodelete
linking dep /usr/lib/libpthread.so.27.1 as child of /usr/local/bin/python3.10
linking dep /usr/lib/libutil.so.18.0 as child of /usr/local/bin/python3.10
linking dep /usr/lib/libm.so.10.1 as child of /usr/local/bin/python3.10
linking dep /usr/lib/libc.so.98.0 as child of /usr/local/bin/python3.10
examining: '/usr/local/lib/libpython3.10.so.0.0'
loading: libutil.so.18.0 required by /usr/local/lib/libpython3.10.so.0.0
loading: libm.so.10.1 required by /usr/local/lib/libpython3.10.so.0.0
loading: libpthread.so.27.1 required by /usr/local/lib/libpython3.10.so.0.0
loading: libintl.so.8.0 required by /usr/local/lib/libpython3.10.so.0.0
linking dep /usr/local/lib/libintl.so.8.0 as child of 
/usr/local/lib/libpython3.10.so.0.0
linking dep /usr/lib/libpthread.so.27.1 as child of 
/usr/local/lib/libpython3.10.so.0.0
linking dep /usr/lib/libutil.so.18.0 as child of 
/usr/local/lib/libpython3.10.so.0.0
linking dep /usr/lib/libm.so.10.1 as child of 
/usr/local/lib/libpython3.10.so.0.0
examining: '/usr/local/lib/libintl.so.8.0'
loading: libiconv.so.7.1 required by /usr/local/lib/libintl.so.8.0
objname [/usr/local/lib/libiconv.so.7.1], dynp 0x172d4183598, objtype 3 lbase 
172d4073000, obase 172d4073000
 flags /usr/local/lib/libiconv.so.7.1 = 0x0
obj /usr/local/lib/libiconv.so.7.1 has /usr/local/bin/python3.10 as head
linking dep /usr/local/lib/libiconv.so.7.1 as child of 
/usr/local/lib/libintl.so.8.0
examining: '/usr/lib/libpthread.so.27.1'
examining: '/usr/lib/libutil.so.18.0'
examining: '/usr/lib/libm.so.10.1'
examining: '/usr/lib/libc.so.98.0'
examining: 

Re: Gajim msyscall error

[Stuart Henderson]

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  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,0x1002,-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
> > > 
> > 
> 

Re: Gajim msyscall error

[Theo de Raadt]

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  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,0x1002,-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
> > 
> 

Re: Gajim msyscall error

[Stuart Henderson]

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,0x1002,-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
> 

Re: Gajim msyscall error

[Lucas Gabriel Vuotto]

On Sat, Mar 02, 2024 at 08:32:04PM +, Lucas Gabriel Vuotto wrote:
> Hello,
> 
> gajim is reporting a msyscall error on launch since today's snapshot.
> 
> 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,0x1002,-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.

Forgot to add dmesg. It's amd64 IBT.

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
real mem = 16868896768 (16087MB)
avail mem = 16336457728 (15579MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x90cb1000 (63 entries)
bios0: vendor LENOVO version "N35ET44W (1.44 )" date 01/28/2022
bios0: LENOVO 20WLS03M00
efi0 at bios0: UEFI 2.7
efi0: Lenovo rev 0x1440
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT TPM2 ECDT HPET APIC SSDT SSDT SSDT 
NHLT SSDT SSDT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM SSDT BATB DMAR MCFG SSDT PTDT 
UEFI FPDT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) GLAN(S4) XHCI(S3) 
XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 2693.79 MHz, 06-8c-01, 
patch 00b4
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 2693.80 MHz, 06-8c-01, 
patch 00b4
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 2693.80 MHz, 06-8c-01, 
patch 00b4
cpu2: