Re: Entering freeze for libvirt-4.6.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 31, 2018 at 02:04:40PM +0200, Martin Kletzander wrote:
> On Tue, Jul 31, 2018 at 10:26:41AM +0200, Michal Privoznik wrote:
> > On 07/30/2018 05:20 PM, Andrea Bolognani wrote:
> > > On Sat, 2018-07-28 at 21:56 +0800, Daniel Veillard wrote:
> > > > 
> > 
> > > 
> > > Unfortunately I've spotted an issue during my testing of rc1 today:
> > > with the libvirt_guest NSS module enabled, Evolution would crash a
> > > few seconds after being started. Here's the stack trace:
> > > 
> > >   #0  0x00007fffe7b69ba5 in json_object_iter_next () at /lib64/libjson-glib-1.0.so.0
> > >   #1  0x00007fffad8e757b in virJSONValueFromJansson () at /lib64/libnss_libvirt_guest.so.2
> > >   #2  0x00007fffad8e75d8 in virJSONValueFromJansson () at /lib64/libnss_libvirt_guest.so.2
> > >   #3  0x00007fffad8e8994 in virJSONValueFromString () at /lib64/libnss_libvirt_guest.so.2
> > >   #4  0x00007fffad8ecb5a in virMacMapNew () at /lib64/libnss_libvirt_guest.so.2
> > >   #5  0x00007fffad8cc140 in findLease () at /lib64/libnss_libvirt_guest.so.2
> > >   #6  0x00007fffad8ccb1c in _nss_libvirt_guest_gethostbyname4_r () at /lib64/libnss_libvirt_guest.so.2
> > >   #7  0x00007fffeb2599d2 in gaih_inet.constprop () at /lib64/libc.so.6
> > >   #8  0x00007fffeb25aab4 in getaddrinfo () at /lib64/libc.so.6
> > >   #9  0x00007ffff1d41a04 in do_lookup_by_name () at /lib64/libgio-2.0.so.0
> > >   #10 0x00007ffff1d3e937 in g_task_thread_pool_thread () at /lib64/libgio-2.0.so.0
> > >   #11 0x00007ffff5c39933 in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
> > >   #12 0x00007ffff5c38f2a in g_thread_proxy () at /lib64/libglib-2.0.so.0
> > >   #13 0x00007ffff6314594 in start_thread () at /lib64/libpthread.so.0
> > >   #14 0x00007fffeb2700df in clone () at /lib64/libc.so.6
> > > 
> > > I've talked about it with a few colleagues and we believe the issue
> > > to be caused by jansson and json-glib both exporting a symbol called
> > > json_object_iter_next: Evolution itself (indirectly?) links against
> > > the latter library, so when the libvirt_guest NSS module is loaded
> > > and attempts to process JSON using the former, it picks up the wrong
> > > implementation, leading to a crash. gnome-boxes also crashes with
> > > the same stack trace.
> > 
> > Worse. querying gentoo portage I've found some important packages
> > requiring json-glib:
> > 
> > x11-libs/gtk
> > gnome-base/gnome-shell
> > 
> > So once users of these app update to latest libvirt they will see the
> > crashes.
> > 
> > > 
> > > It seems like a similar issue could affect any application linking
> > > both to libvirt and json-glib, regardless of whether or not the NSS
> > > plugin has been enabled, which is of course pretty bad.
> > 
> > Yes, any application can crash.
> > 
> > > 
> > > Unfortunately, I don't have any bright ideas on how to solve this,
> > > so anyone who might: please step forward! We're just a few days
> > > away from the next release, and if we can't figure out a way around
> > > this soon I'm afraid the only reasonable course of action would be
> > > to (temporarily) revert the switch from yajl to jansson.
> > > 
> > 
> > Well, what if we linked with jansson statically? I'm not sure if it is
> > possible (and have no idea how to achieve that), but what if our dynamic
> > libraries we produce already contained jansson and thus linker would not
> > even try to resolve json_* symbols.
> > 
> 
> It could "help" (quotes for all the disadvantages that approach has).  Not
> because it would not try to resolve it, but because we would have the `json_`
> symbols as 'local' thanks to our src/libvirt.syms.  If the lib was added to our
> dynamic lib we would still need to use `-Bsymbolic-functions` so that our
> `json_` symbols don't call `json_` symbols from the dynamic one programs where
> it is loaded.  However that has some issues with `LD_PRELOAD`.

Note there is no jansson static build in Fedora or RHEL, so it is somewhat
academic right now.

> 
> Maybe we could utilize the `-Bgroup` linker option, although I'm not sure how
> that is supposed to be used.
> 
> In any case, this could be fixed in the respective libraries.  The reasoning
> behind it is that since C doesn't support namespaces we namespace functions by a
> prefix (`vir` in libvirt), however that "namespace" needs to be unique.  They
> should switch to `jansson_` or `glib_json_` prefixes and maybe provide macros
> for the previous names:
> 
>  #define json_auto_t jansson_auto_t
>  ...
> 
> I know it sounds like too big of a deal, but that's what happens in C world.
> The same would happen if libvirt used `json-glib` and some application linking
> with libvirt would start using jansson (and also use some specific functions).
> Not that we were guarded against that now.  I'm not saying the release can go
> on, of course not, just that the ultimate fix is not something *we* should do.

Changing their API names isn't required unless you need to have separation
of namespaces at the #include level, so you can pull in both.

For ELF libraries, it would be sufficient to have symbol versioning to get
separation.

> Querying the fedora repositories I haven't found any similar situation.
> Projects that use jansson are separated from those that use json-c and those
> that use json-glib.  If they want to use each other though, we'll be in the same
> mess as we are now.

GNOME control center + NetworkManager hit this problem in Fedora.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux