On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> On Sun, Mar 03, 2024 at 11:58:51AM +0000, 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.
<snip>
> 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 0x0000098b93dc7d01 in py_dl_open () from
/usr/local/lib/python3.10/lib-dynload/_ctypes.cpython-310.so
#2 0x0000098bb0dc1bc1 in cfunction_call () from
/usr/local/lib/libpython3.10.so.0.0
#3 0x0000098bb0d6a132 in _PyObject_MakeTpCall () from
/usr/local/lib/libpython3.10.so.0.0
<snip>
so something is doing dlopen("libc.so.99.0", RTLD_NOW) ...
(gdb) py-bt
Traceback (most recent call first):
<built-in method dlopen of module object at remote 0xce92ca2bab0>
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 <module>
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.
