Not Finding the Symbols

Yesterday we released the new version of the MongoDB Driver for PHP, to coincide with the release of MongoDB 3.4. Not long after that, we received an issue through GitHub titled "Undefined Symbol php_json_serializable_ce in Unknown on Line 0".

TL;DR: Load the JSON extension before the MongoDB extension.

The newly released version of the driver has support for PHP's json_encode() through the JsonSerializable interface, to convert some of our internal BSON types (think MongoDB\BSON\Binary and MongoDB\BSON\UTCDateTime) directly to JSON. For this it uses functionality in PHP's JSON extension, and with that the php_json_serializable_ce symbol that this extension defines.

We run our test suite on many different distributions, but (nearly) always with our own compiled PHP binaries as we need to support so many versions of PHP (5.4-5.6, 7.0, and now 7.1), in various configurations (ZTS, or not; 32-bit or 64-bit). It came hence quite as a surprise that a self-compiled extension would not load for one of our users.

When compiling PHP from its source, by default the JSON extension becomes part of the binary. This means that the JSON extension, and the symbols it implements are always available. Linux distributions often split out each extension into their own package or shared object. Debian has php5-json (on which php5-cli depends), while Fedora has php-json. In order to make use of the JSON extension, you therefore need to install a separate package that provides the shared object (json.so) and a configuration file. Fedora installs the 20-json.ini file in /etc/php.d/. Debian installs the 20-json.ini file in /etc/php5/mods-available with a symlink to /etc/php5/cli/conf.d/20-json.ini. In both cases, they include the required extension=json.so line that instruct PHP to load the shared object and make its symbols (and PHP functions) available.

A normal PHP binary uses the dlopen system call to load a shared object, with the RTLD_LAZY flag. This flag means that symbols (such as php_json_serializable_ce) are only resolved lazily, when they are first used. This is important, because PHP extensions and the shared objects they live in, can depend on each other. The MongoDB extension depends on date, spl and json. After PHP has loaded all the shared extensions, it registers the classes and functions contained in them, in an order to satisfy this dependency graph. PHP makes sure that the classes and functions in the JSON extension are registered before the MongoDB extension, so that when the latter uses the php_json_serializable_ce symbol to declare that the MongoDB\\BSON\\UTCDateTime class implements the JsonSerializable interface the symbol is already available.

Distributions often want to harden their provided packages with additional security features. For that, they compile binaries with additional features and flags.

Debian patches PHP to replace the RTLD_LAZY flag with RTLD_NOW. Instead of resolving symbols when they are first used, this signals to the dlopen system call to resolve the symbols when the shared object is loaded. This means, that if the MongoDB extension is loaded before the JSON extension, the symbols are not available yet, and the linker throws the "Undefined Symbol php_json_serializable_ce in Unknown on Line 0" error from our bug report. This is not a problem that only related to PHP; TCL has similar issues for example.

With Fedora, the same issue is present, but shows through slightly different means. Instead of patching PHP to replace RTLD_LAZY with RTLD_NOW, it uses linker flags ("-Wl,-z,relro,-z,now") to force binaries to resolve symbols as soon as they are loaded process wide. This Built with BIND_NOW security feature goes hand in hand with Built with RELRO. The explanation on why these features are enabled on Fedora is well described on their wiki. Previously, this did expose an issue with an internal PHP API regarding creating a DateTime object.

But where does this leave us? The solution is fairly simple: You need to make sure that the JSON extension's shared object is loaded before the MongoDB extension's shared object. PECL's pecl install suggests to add the extension=mongodb.so line to the end of php.ini. Instead, on Debian, it would be much better to put the extension=mongodb.so line in a separate 99-mongodb.ini file under /etc/php5/mods-available, with a symlink to /etc/php5/cli/conf.d/99-mongodb.ini and /etc/php5/apache2/conf.d/99-mongodb.ini:

cat << EOF > /etc/php5/mods-available/mongodb.ini
; priority=99
extension=mongodb.so
EOF
php5enmod mongodb

On Fedora, you should add the extension=mongodb.so line to the new file /etc/php.d/50-mongodb.ini:

echo "extension=mongodb.so" > /etc/php.d/50-mongodb.ini

Alternatively, you can install the distribution's package for the MongoDB extension. Fedora currently has the updated 1.2.0 release for Rawhide (Fedora 26). Debian however, does not yet provide a package for the latest release yet, although an older version (1.1.7) is available in Debian unstable. At the time of this writing, Ubuntu only provides older versions for Xenial and Yakkety.

Shortlink

This article has a short URL available: https://drck.me/undefsym-cpv

Comments

Adding "extension=mongodb.so" at the end of php.ini didn't solve the issue but 99-mongodb.ini did! Thanks! BTW $ uname -a Linux titanic 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

Made new file mongodb.ini

added 2 lines ; priority=99 extension=mongodb.so

& run command phpenmod mongodb

This worked for me. I had to remove extension=mongodb.so from php.ini file

On Ubuntu 14 & php 7 ( Working on Vagrant )

Thanks for the info, I tried just sticking extension=json.so one line above in the php.ini and that worked for me

I was using a standard AWS image. And the following worked for me: # Don't add extension to /etc/php-5.6.ini echo "extension=mongodb.so" > /etc/php.d/50-mongodb.ini echo "extension=mongo.so" > /etc/php.d/50-mongo.ini

Add Comment

Name:
Email:

Will not be posted. Please leave empty instead of filling in garbage though!
Comment:

Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.


All comments are moderated

Life Line