GNOME Bugzilla – Bug 703734
gnome-control-center links with both json-c and json-glib
Last modified: 2013-09-22 12:09:03 UTC
As reported downstream in: https://bugs.gentoo.org/show_bug.cgi?id=475954 "All the versions of dev-libs/json-glib currently in the portage tree (I found 0.14.2, 0.15.2 and 0.16.0) define the following macro in json-glib/json-types.h (line 103 in 0.16): #define JSON_TYPE_OBJECT (json_object_get_type ()) The json_object_get_type() function comes from dev-libs/json-c. In json-c-0.9 it is implemented as follows (in json_object.c, line 184-187): enum json_type json_object_get_type(struct json_object *jso) { return jso->o_type; /* <-- this is line 186 */ } Since json_glib calls the function with no arguments, this causes a segmentation fault (illegal dereference of null pointer). Here is an example, caused by trying to add a gnome online account in Gnome 3: $ gdb gnome-control-center GNU gdb (Gentoo 7.5.1 p2) 7.5.1 ... ... (gdb) run Starting program: /usr/bin/gnome-control-center ... ... Program received signal SIGSEGV, Segmentation fault. 0x00007fffedb893cb in json_object_get_type (jso=0x0) at json_object.c:186 In version 0.10 and above of json-c, the json_object_get_type() is defined like this (in json_object.c, line 176-181): enum json_type json_object_get_type(struct json_object *jso) { if (!jso) return json_type_null; return jso->o_type; } which deals gracefully with the null argument, avoiding the segmentation fault." Thanks!
that doesn't make whatsoever sense; json-glib is not implemented in terms of json-c, and using them both at the same time is non-sensical: you either use json-glib *or* you use json-c.
But, in the system, there are packages needing json-c (like pulseaudio) and others json-glib... then, we need to support a situation with both installed at the same time
both libraries installed at the same time does not imply that both are linked at the same time or used at the same time. if a library or an application is using JSON-GLib and json-c at the same time (either directly or through dependencies), then it's a library or an application bug and it should be solved at that level. json-glib does *not* link against json-c, and it has no business detecting json-c in its configuration script. json_object_get_type() in json-glib is *not* calling the same function in json-c.
(In reply to comment #0) in fact, this sentence: > "All the versions of dev-libs/json-glib currently in the portage tree (I found > 0.14.2, 0.15.2 and 0.16.0) define the following macro in json-glib/json-types.h > (line 103 in 0.16): > > #define JSON_TYPE_OBJECT (json_object_get_type ()) > > The json_object_get_type() function comes from dev-libs/json-c. is utterly wrong. json_object_get_type() comes from json-glib itself, and it's defined by the G_DEFINE_BOXED_TYPE macro here: https://git.gnome.org/browse/json-glib/tree/json-glib/json-object.c#n52 > $ gdb gnome-control-center > GNU gdb (Gentoo 7.5.1 p2) 7.5.1 > ... > ... > (gdb) run > Starting program: /usr/bin/gnome-control-center > ... > ... > > Program received signal SIGSEGV, Segmentation fault. > 0x00007fffedb893cb in json_object_get_type (jso=0x0) at json_object.c:186 this is ridiculous. gnome-control-center is either directly or indirectly linking against both json-c and json-glib. it should stop doing that. json_object_get_type() returns a GType for the JsonObject boxed type to be used in signals and properties marshallers; mixing it with json-c's function will inevitably yields bugs, segfaults, or a giant ASCII middle finger pasted on your screen. please, file a bug against gnome-control-center to either drop json-glib or json-c.
Can not you reassign this bug to that component instead? (to not duplicate all the reasoning)
re-assigning.
Thanks!
In this case, the dependency on json-glib comes from clutter, and the json-c dependency from pulseaudio which causes a symbol collision during linking. One way to fix this is by passing -Bsymbolic-functions to the linker while creating the shared library.
Clutter already uses -Bsymbolic-functions — I guess pulseaudio needs to do that as well.
Hello, I am the original reporter of the issue on the gentoo bug list ;) Now, forgive my ignorance, I am new to glib and gtk+, so was not aware of the (apparently non-existant) relationship between json-glib and json-c; but ebassi's explanations all seem perfectly clear to me; for some reason in the Gentoo gnome 3.8 setup, gnome-control-center ends up calling the wrong json_object_get_type() function from the wrong dynamic library, which causes the segfault. No continuing in my ignorance, I reasoned that it is a function in json-glib which is calling json_object_get_type() and expecting to find its own implementation, but incorrectly ending up with the version from json-c instead. Therefore I would expect that by compiling json-glib with -Bsymbolic-functions I could ensure that those same json-glib functions will always end-up with their own local json_object_get_type() version, no matter what other libs might have been linked in to the final executable. I proceeded to try this out, by first reverting to the old json-c 0.9 on my system (to make sure I'd get a segfault if its json_object_get_type gets called), and then rebuilding json-glib with -Bsymbolic-functions. And lo and behold, the segfault went away... In fact, by inserting an extra printf() in the json_object_get_type() function (using G_DEFINE_BOXED_TYPE_WITH_CODE en lieu of the origin in json-glib/json-object.c) I can see that now the correct version is being called. In light of this, is there anything wrong with using -Bsymbolic-functions on json-glib itself, thereby alleviating the necessity for hunting down the entire dynamic library dependence tree of gnome-control-center and gnome-online-accounts? Once again, I am just asking, I am new to glib and gnome... ;)
Created attachment 248943 [details] [review] build: Add configure option to enable -Bsymbolic We should always compile with -Bsymbolic enabled to avoid intra-library PLT jumps.
Review of attachment 248943 [details] [review]: Ah, a casualty of Lennart's stack of stuff pulling in a non-GLib alternative universe =/ Anyways, this looks correct to me.
(In reply to comment #11) > Created an attachment (id=248943) [details] [review] > build: Add configure option to enable -Bsymbolic > > We should always compile with -Bsymbolic enabled to avoid intra-library > PLT jumps. What's this patch against?
(In reply to comment #13) > (In reply to comment #11) > > Created an attachment (id=248943) [details] [review] [details] [review] > > build: Add configure option to enable -Bsymbolic > > > > We should always compile with -Bsymbolic enabled to avoid intra-library > > PLT jumps. > > What's this patch against? The patch is for json-glib. The product should probably be fixed to reflect that.
Attachment 248943 [details] pushed as a932748 - build: Add configure option to enable -Bsymbolic
*** Bug 705296 has been marked as a duplicate of this bug. ***
Emmanuelle, instead of calling things ridiculous and utterly wrong can you please reflect on why you chose the namespace json for json-glib's symbols? I would think that json-c's namespace ought to be json_ and json_glib's namespace ought to be gjson or something else. The bug is yours, no matter what aggressive attitude you have.
oh, Philip. please, don't involve yourself in matters beyond your reading skill and comprehension. also, you still haven't learned how to write my name.
(In reply to comment #18) > oh, Philip. please, don't involve yourself in matters beyond your reading skill and and comprehension Hmm right. This attitude verifies my thoughts on your aggressive attitude. > also, you still haven't learned how to write my name. I'll do my best the day you earn my respect. That's not today, Emmanuelle. On the subject I think you should change the namespace of your GLib based JSON library and allow json-c to have the symbols they need (in other words, get out of the way of json-c). I don't think -Bsymbolic-functions is the right solution and I think that your aggressive style is harming the open source community more than it is helping. Good luck.
(In reply to comment #19) > (In reply to comment #18) > > oh, Philip. please, don't involve yourself in matters beyond your reading skill and and comprehension > > Hmm right. This attitude verifies my thoughts on your aggressive attitude. and your attitude reminds me that you're a clown that has no better things to do than troll on closed bugs much to the annoyance of everybody Cc:-ed on them. I guess that's what happens when you're not trolling on foundation-list. go. away. > > also, you still haven't learned how to write my name. > > I'll do my best the day you earn my respect. That's not today, Emmanuelle. this is hilarious. you're confused on what "respect" means, by the way. > On the subject I think you should change the namespace of your GLib based JSON > library and allow json-c to have the symbols they need (in other words, get out > of the way of json-c). I don't think -Bsymbolic-functions is the right solution there is no discernible reason why anyone should directly link against two separate JSON parsing libraries — which is the only case that is not covered by the -Bsymbolic-functions linker flag. indirect conflicts (which is the case of this bug) are fixed by that flag. changing the JSON-GLib namespace requires creating a new, parallel installable library, as well as porting all applications that link against JSON-GLib to that new library. feel free to fork JSON-GLib and do all that. at least, you'll use your time more productively than expressing unfounded opinions on bug reports.