HHVM v3.13.0 Silently Fails, Causing “Bad Gateway” Errors

If you’re suddenly getting “Bad Gateway” errors on your HHVM setup and it’s happened in the last week or so, it’s probably this problem.

In a nutshell, HHVM running in daemon mode seems to silently crash (leaving no error messages that I could find) after serving a few requests. On this server it would crash instantly if a fatal error was generated, but it seemed to serve several normal requests fine before finally dying.

Running under server mode it seems to work as normal.

Updated 2016-04-07 – as per the Github linked above this is now fixed in v3.13.1.

502 Bad Gateway errors after upgrading to v3.7.3

The HHVM team just released a new update to fix an SSL issue – more details available here.

After upgrading to the new version (v3.7.3 if you’re running out of latest Debian, or v3.3.7/v3.6.5 if you’re running older versions), my HHVM would not restart, yielding a 502 Bad Gateway error when loading this site.

The error log (/var/log/hhvm/error.log) had the following error:

Failed to initialize central HHBC repository:\n Failed to initialize schema in /var/run/hhvm/hhvm.hhbc: RepoQuery::step(repo=0x7f32f1c3bc00) error: ‘CREATE TABLE main.UnitLineTable_6ba408ef27e1fc7820c8bd6352989f40c1acb812(unitSn INTEGER PRIMARY KEY, data BLOB);’ –> (13) database or disk is full\n Failed to open /root/.hhvm.hhbc: 14 – unable to open database file\n Failed to open /var/www/.hhvm.hhbc: 14 – unable to open database file\n

I deleted /root/.hhvm.hhbc and restarted, which didn’t fix it, but /var/www/.hhvm.hhbc did not exist. I found a /var/run/hhvm/hhvm.hhbc which I deleted; restarting HHVM at that point (via /etc/init.d/hhvm restart) then had the site back up and running.

Minor issues upgrading to HHVM v3.3.0

HHVM v3.3.0 landed a couple of days ago – the first HHVM to be released with long-term support.

I just upgraded this VPS (via apt-get upgrade) and had a few issues:

– Restarting HHVM yielded the following error message:

/usr/bin/hhvm: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory

This was solved with:

apt-get install libgmp-dev

– However, after installing libgmp, the following error turned up:

/usr/bin/hhvm: error while loading shared libraries: libmemcachedutil.so.2: cannot open shared object file: No such file or directory

Solved by installing libmemcached:

apt-get install libmemcached-dev

– Also after upgrading, this WordPress website was replaced with the default index.html from nginx. Not sure how that happened; deleting the index.html file fixed that.

Solving the unexpected ‘:’ error in XHP files under HHVM

If you’ve set up a new instance of HHVM and are trying to get XHP to work, you might hit the following error showing up in your error log:

Fatal error: syntax error, unexpected ‘:’ in /www/core.php on line 18

In my case, I’d deployed the correct files from the XHP Github and everything else looked correct, but any file with XHP code was yielding the above.

The fix is simple: change the <?php tags at the top of the three files (core.php, init.php and html.php) to <?hh .

Now supporting XHP out of the box

I realised that the initial version of the deploy script didn’t support XHP, the new markup language devised by the Facebook team.

I’ve updated the script so that it will automatically configure the test product to support XHP natively. It will create a new file in the web root – test_xhp.php – which will allow you to quickly test and make sure XHP is working.

A new HipHop way to WordPress

The first version of my Binary Lane Deployment Script to deploy WordPress under Nginx and HHVM is now online.

Note that it is a rough beta intended for new servers only – it may destroy content on old servers, so use with caution.

To use WP Super Cache with this setup, you can use the following in your server{} section within the Nginx configuration (source):

set $supercache_file '';
set $supercache_uri $request_uri;

if ($request_method = POST) {
set $supercache_uri '';

# Using pretty permalinks, so bypass the cache for any query string
if ($query_string) {
set $supercache_uri '';

if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
set $supercache_uri '';

# if we haven't bypassed the cache, specify our supercache file
if ($supercache_uri ~ ^(.+)$) {
set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;

# only rewrite to the supercache file if it actually exists
if (-f $document_root$supercache_file) {
rewrite ^(.*)$ $supercache_file break;

# all other requests go to WordPress
if (!-e $request_filename) {
rewrite . /index.php last;

Test reference site for WordPress running under HHVM on Binary Lane