On Mon, Jul 30, 2018 at 05:20:01PM +0200, Andrea Bolognani wrote:
On Sat, 2018-07-28 at 21:56 +0800, Daniel Veillard wrote:
> so things looks pretty good for
> me but please try it out on different systems and OSes.
>
> If everything goes well I will push rc2 on Tuesday targetting Thursday for the
> final release (or Friday if I get stuck in travels).
>
> thanks in advance for trying it out !
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.
Frustratingly both jansson and json-glib use the same 'json_' prefix
for all their functions, which was very unwise choice of namespaces.
Despite this by some miracle 'json_object_iter_next' is the only
one that clashes.
This is compounded by neither library making use of symbol versioning
which would have ensured they resolved to the correct libraries. We
should talk to them about adding versioning to avoid this problem.
I wondered if it is possible for libvirt to change its impl to avoid
calling json_object_iter_next, but it doesn't look practicall, as
'json_object_foreach' just uses the iter behind the scenes.
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.
Sure, it affects applications for any library libvirt links to
in fact. Most libraries use the library name as the base prefix
for their methods to get good namespacing. Unfortunately this
time both libraries used the generic 'json_' prefix.
I'm not so worried about this though, as the code paths taken
in the libvirt client shouldn't tickle the json parser. Of
course if jansson gets resolved before json-glib, we could
still break the apps own usage of json.
The NSS module is the big worry since that's loadable by any
process.
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.
Or just document it as a known issue in the NSS module for now
and resolve in next release.
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 :|