On Tue, 2016-04-26 at 08:52 +0530, Arun Raghavan wrote:
> Okay, so this is a fun one. The offending commit is:
>
> Â commit 12a202c510dcacbd2b85fcc1170484eb16fef491
> Â Author: Arun Raghavan <git at arunraghavan.net>
> Â Date:Â Â Â Thu Dec 31 09:27:56 2015 +0530
>
> Â Â Â Â Â Â format: Make pa_format_info_valid() stricter for PCM
> Â Â Â
> Â Â Â Â Â Â We should do stricter validation when we can.
>
> The check fails at:
>
> Â if (json_object_get_type(o) != json_type_string) {
> Â Â Â Â Â Â pa_log_debug("Format info property '%s' type is not string.", key);
> Â Â Â Â Â Â json_object_put(o);
> Â Â Â Â Â Â return -PA_ERR_INVALID;
> Â }
>
> Rhythmbox and Totem are linked to the json-glib library which *also*
> has a json_object_get_type(). That is the function which gets called,
> and returns a junk type which makes this code fail.
>
> I don't know what the right way to fix this sort of situation with
> colliding symbols. The worst case, I guess, is to drop json-c
> altogether and maybe just do our own lightweight parsing for these
> strings. Would be nice to not have to do that right now, though, so I'm
> all ears for suggestions.
We've had this problem before. According to this[1] blog post, the
issue was fixed earlier by linking json-glib with -Bsymbolic. The
option forces json-glib's internal json_object_get_type() calls to
always use json-glib's own implementation, but I don't think it helps
applications that use json-glib.
We have many other json_object_get_type() calls in the code too. I
don't know why those don't cause as bad results...
Do you remember what motivated you to write the patch that caused this
breakage? It looks like something that we could somewhat safely just
revert for 9.0. After the 9.0 release, however, I think we really
should either get rid of the json-c dependency, or bundle it in
pulseaudio and link to it statically.
I think it would also be possible to add symbol versioning to json-c.
That should allow us to use some magic incantations in our code to
force our code to link to json-c, but it still wouldn't guarantee that
applications don't end up linking to json-c when they intend to use
json-glib.
[1]Â https://blogs.gnome.org/ebassi/2013/09/16/do-not-link-against-pulseaudio-and-json-glib-0-16/
--
Tanu
