[LINUX] crash using "json_object_iter_next" function

[CicTec]

Hello,

I'm using jansson in a library project for Linux.

The library is compiled at 64bit in Ubuntu 16.04 LTS 64bit

After compiling the static jansson library using CMake and linking it to the library, I noticed that there seems to be a conflict with the JSON-C library if it is installed in the system using the "json_object_iter_next" function (in both libraries the same function exists), here an example of a crash that the debugger tells me when I call the jansson function: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff1313700 (LWP 21219)]

Thread 1 "webservices_06_" received signal SIGSEGV, Segmentation fault. 0x00007ffff4a8b1c3 in json_object_iter_next ()    from /lib/x86_64-linux-gnu/libjson-c.so.2

I also tried to compile all the jansson code directly inside the library I'm developing (without including dependencies of other libraries), but the result is the same.

Someone would know if there is some setting to avoid this or is it a bug in the library to be corrected?

[coreyfarrell]

Looks like 360b1ef5a1811594751234ffe630beabd138ba2e needs to be ported to CMake (sorry I'm not that good with CMake so I can't help with this).

The only work-around right now is to build using the configure script + make.

[ploxiln]

I think -Bsymbolic-functions does not help for static library archives.

[CicTec]

Hello again,

Based on your information I've done several tests, here the results in case they can help other people or to improve the jansson scripts:

1. compiled the static library jansson using "configure + make" and linking it to the dynamic library in development, produces an "Indipendent code" error, the jansson library should be compiled with -fPIC at least for the 64bit version.

2. compiled the static library jansson by "cmake" and linking it to the dynamic library in development, the build is done correctly, but using the function "json_object_iter_next" produces a crash for the error mentioned in the first post.

3. compiled the static library jansson by "cmake" adding the line to the cmakelists: set_target_properties (jansson PROPERTIES LINK_FLAGS "-Wl, -Bsymbolic-functions") and linking it to the dynamic library in development, the build is done correctly, but using the function "json_object_iter_next" it produces a crash due to the error mentioned in the first post.

4. compiled the jansson library directly in the dynamic library in development, the build is done correctly, but using the function "json_object_iter_next" produces a crash due to the error mentioned in the first post.

5. compiled the static library jansson by "cmake" and linking it to the dynamic library in development, adding to this the linker option "-Wl, -Bsymbolic-functions" and, the build is done correctly, and the function "json_object_iter_next" no longer gets conflict with other installed libraries, working properly.

6. compiled the jansson library directly in the dynamic library in development, adding to this the linker option "-Wl, -Bsymbolic-functions", the build is done correctly, and the function "json_object_iter_next" does not get more conflict with other installed libraries, working correctly .

Thanks for the help and I hope the info can be useful.

Regards.

[i-ky]

I'm sorry for necroposting, but the issue is still open, so...

I've encountered a lot of such name conflicts at my previous job. Eventually this little project was born. I'm not sure if it can be of any use in case of static libraries, but for dynamic libraries it can provide a workaround.

On some platforms libraries can provide versioned symbols.

[ploxiln]

symbol versioning was added to both jansson (in https://github.com/akheron/jansson/pull/540) and json-c (in https://github.com/json-c/json-c/pull/639)

[i-ky]

Oh, I should have checked this. Great news!

[sochotnicky]

@akheron Any chance you're planning a release that would include the symbol versioning changes? Lack of versioned symbols causes crashes and other hard to debug issues and quick check through a few distributions show that they have not cherry-picked the change and seem to be either unaware of the problem or waiting for a new release