Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 475954 - >=dev-libs/json-glib-0.14.2 should be compiled with -Bsymbolic-functions
Summary: >=dev-libs/json-glib-0.14.2 should be compiled with -Bsymbolic-functions
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
: 480756 (view as bug list)
Depends on:
Blocks: gnome-3.8 470200
  Show dependency tree
Reported: 2013-07-06 15:10 UTC by James Bates
Modified: 2013-08-13 18:53 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description James Bates 2013-07-06 15:10:42 UTC
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.

I therefore suggest, as in the title, >=dev-libs/json-glib-0.14.2 should depend on >=dev-libs/json-c-0.10 to ensure that the segfault does not occur.

I realize that in theory it is up to the upstream maintainers of json-glib to ensure that their configure-run should fail if a version of json-c is detected which doesn't catch the null pointer. But as it stands today they have not done so, and Gentoo users are receiving segfaults because of it. So maybe we could be nice to the Gentoo users, and inset the dependency? ;)

Here is what I changed in json-glib-0.16.0.ebuild to ensure pulling in the correct json-c version:

--- /usr/portage/dev-libs/json-glib/json-glib-0.16.0.ebuild	2013-04-25 21:39:10.000000000 +0200
+++ /usr/local/portage/dev-libs/json-glib/json-glib-0.16.0.ebuild	2013-07-06 16:55:47.000000000 +0200
@@ -17,6 +17,7 @@
+	>=dev-libs/json-c-0.10
 	introspection? ( >=dev-libs/gobject-introspection-0.9.5 )
json-glib-0.14.2.ebuild and json-glib-0.15.2.ebuild require something similar.

Now I - also - realize that dev-libs/json-c-0.10-r1 is ~* whereas dev-libs/json-glib-0.14.2 is mostly not... But all the same, I believe the current state is wrong, since 0.14.2 contains that macro definition in json-types.h, and therefore will in all circumstances cause a segfault if running the implementation from json-c-0.9 or below. Might I respectfully suggest that you guys get a move on removing the ~* keywords from dev-libs/json-c-0.10-r1 ;)

Kind regards,
James Bates

Reproducible: Always

Steps to Reproduce:
1. Make sure you don't automatically pull in dev-libs/json-c-0.10-r1 or later, either by avoiding any general keywords like ACCEPT_KEYWORDS="~amd64 ~x86" and such like and by making sure it isn't mentioned in package.keywords, or by explicitly masking >=dev-libs/json-c-0.10 in package.mask.
2. emerge something that depends on dev-libs/json-glib, e.g. =net-libs/gnome-online-accounts-3.8.2
3. In the case of gnome-online-accounts, try adding an online account from the gnome-control-center ("Settings" in the top-right user menu)
Actual Results:  
When adding e.g. a Google or facebook account, a segmentation fault occurs (during parsing of the oAuth response json from the online provider), and the account is not added.

Expected Results:  
No segmentation fault occurs, and the account is added correctly.
Comment 1 Pacho Ramos gentoo-dev 2013-07-07 05:37:13 UTC
This is probably the cause of bug 470200
Comment 2 James Bates 2013-07-11 15:22:09 UTC
It would seem (see discussion at that json-lib doesn't actually, in fact shouldn't depend on json-c at all.

Only, if both libs get linked to an executable for whatever reason, functions in json-lib which call json_object_get_type(), thinking they are calling a local function, actually end up with the json-c version which has exactly the same name, and this causes the segfault.

Therefore the solution would appear not be to adjust dependencies, but to ensure that json-lib gets linked with -Bsymbolic-functions, so that it will always look for json_object_get_type() (and any other symbols) inside itself first.

This can be achieved by modifying the build as follows:

james@hermes:~$ diff -u /usr/{,local/}portage/dev-libs/json-glib/json-glib-0.16.0.ebuild 
--- /usr/portage/dev-libs/json-glib/json-glib-0.16.0.ebuild	2013-04-25 21:39:10.000000000 +0200
+++ /usr/local/portage/dev-libs/json-glib/json-glib-0.16.0.ebuild	2013-07-11 17:20:54.000000000 +0200
@@ -5,7 +5,7 @@
-inherit gnome2
+inherit gnome2 autotools
 DESCRIPTION="A library providing GLib serialization and deserialization support for the JSON format"
@@ -25,6 +25,14 @@
+src_prepare() {
+	epatch ${FILESDIR}/dynamic-functions.patch
+	eautoreconf
+	gnome2_src_prepare
 src_configure() {
 	# Coverage support is useless, and causes runtime problems
 	gnome2_src_configure \

and including the following json_glib/ patch in ${FILESDIR}

james@hermes:~$ cat /usr/local/portage/dev-libs/json-glib/files/dynamic-functions.patch 
--- json-glib/	2013-07-11 16:14:24.000000000 +0200
+++ json-glib/	2013-07-11 16:13:42.000000000 +0200
@@ -78,7 +78,7 @@
 libjson_glib_1_0_la_LIBADD = $(JSON_LIBS)
 libjson_glib_1_0_la_SOURCES = $(source_c) $(source_h) $(source_h_private) $(BUILT_SOURCES)
-libjson_glib_1_0_la_LDFLAGS = $(JSON_LT_LDFLAGS) $(JSON_GCOV_LDADD) -no-undefined -export-symbols $(top_srcdir)/json-glib/json-glib.symbols -rpath $(libdir)
+libjson_glib_1_0_la_LDFLAGS = $(JSON_LT_LDFLAGS) $(JSON_GCOV_LDADD) -no-undefined -export-symbols $(top_srcdir)/json-glib/json-glib.symbols -rpath $(libdir) -Wl,-Bsymbolic-functions
 EXTRA_DIST += json-glib.symbols
Comment 3 James Bates 2013-07-17 08:40:41 UTC
Better patch located here:
Comment 4 Pacho Ramos gentoo-dev 2013-07-20 11:28:47 UTC
+*json-glib-0.16.0-r1 (20 Jul 2013)
+  20 Jul 2013; Pacho Ramos <>
+  +files/json-glib-0.16.0-bsymbolic.patch, +json-glib-0.16.0-r1.ebuild,
+  -json-glib-0.16.0.ebuild:
+  Apply upstream patch to use bsymbolic and prevent problems like bug #475954
Comment 5 Pacho Ramos gentoo-dev 2013-08-13 18:53:48 UTC
*** Bug 480756 has been marked as a duplicate of this bug. ***