Reporting HHVM crashes properly, so the reports are actionable, takes a bit of effort at the moment. We don't currently have a mechanism for automatically reporting crashes or even uploading cores but it's important in getting the issues fixed both for the reporter and the entire community. We appreciate when you take the time to do so.
Here are some tips on how to report a crash in a way that someone familiar with the codebase can analyze without needing to immediately ask for more information:
Reproducing a crash in a debug build built from source ensures that the bug hasn't already been fixed and provides a maximum amount of diagnostic information. Please provide a backtrace gathered in this manner. (To build debug, run cmake with
Providing a small and isolated case which can be used to reproduce the issue will exponentially increase the chances of someone being able to diagnose and fix the issue.
If a crash is in the machine code that HHVM (in JIT mode) generates at runtime, the backtrace alone will be completely unhelpful by default. Such crashes will always have the following two frames on the top of the stack:
(gdb) bt #0 0x0000000005c396a9 in ?? () #1 0x0000000000f2211e in enterTCHelper () ...
If the crash is a JIT crash, then an IR dump will be needed to determine what HHVM was doing when it crashed. To produce such a dump, reproduce the crash with
TRACE=printir:2 in the environment and a logfile will be generated (by default /tmp/hphp.log) that contains the IR.
GDB will also produce more useful output if HHVM is run with the commandline arguments:
Please provide, along with the backtrace, a link to this file using gist or some other storage as it is likely to be large in any real PHP application.
hhvm-gdbcommand, it is a wrapper script to automatically load gdb macros for you.