HHVM using way more memory in v3.14

Since the 3.14 version of HHVM, I haven’t been able to run it at all – it would crash on load with a memory error (“Failed to mmap persistent RDS region”). This VPS has been running happily with only 512MB of RAM, but this latest update must’ve pushed it over the line.

I tried a bunch of things to tweak the memory usage but in the end simply couldn’t get it to load; I’ve simply added another 256MB of RAM and now it works fine.

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.