Last modified: 2014-11-14 06:52:42 UTC
Add a line like foo()bar(); to your php. Localhost says `This webpage is not available` I can't find the php error logs so I can't debug it. I'm sure they exist somewhere but why don't these kind of errors output to the screen?
Check /vagrant/logs/hhvm/error.log. I agree that we should figure out how to tune HHVM's error reporting to be nicer for development work.
Nothing in there for me. :-/
Change 171443 had a related patch set uploaded by MaxSem: Output HHVM errors to the user https://gerrit.wikimedia.org/r/171443
Change 171443 abandoned by MaxSem: Output HHVM errors to the user Reason: Eh https://gerrit.wikimedia.org/r/171443
So what happens is that MW sets up home-made gzipping and sends Content-Encoding:gzip, however when it crashes, HHVM outputs the error in plaintext, choking browser's decoder.
(In reply to Max Semenik from comment #5) > So what happens is that MW sets up home-made gzipping and sends > Content-Encoding:gzip, however when it crashes, HHVM outputs the error in > plaintext, choking browser's decoder. I've poked at this problem a bit today and found out some things. First, HHVM's error log should be written to /vagrant/logs/hhvm/error.log. I can confirm on several test vms that this works for me. I can also confirm however that the HHVM interpreter buffers it's log writes such that errors may not be written to this file immediately. I looked through the code a bit and couldn't find a setting that would disable this caching or make it flush faster. The next thing I've figured out is that you get slightly different results based on where the error is located. If I add the "foo()bar();" invalid PHP syntax in a file like $IP/index.php I get an error page from HHVM. It's an ugly page and it has a 200 response status, but it is an error page. If I bury the syntax error somewhere like in the middle of CoreParserFunctions::ns() I just get an empty "500 hphp_invoke" response from the server. If I wait long enough then I see a parse failure in the error.log file. This corresponds to what Max is reporting in the context-encoding mismatch. If the error happens before we set that header you will se something, but after the header is set everyone gets confused.
Minimum repro: <?php header( 'Content-Encoding: gzip' ); echo gzencode( somefunc() );
Change 172002 had a related patch set uploaded by MaxSem: Don't use output compression https://gerrit.wikimedia.org/r/172002
Change 172002 merged by jenkins-bot: Don't use output compression https://gerrit.wikimedia.org/r/172002
Jon, does it fix the issue for you?
I see errors now. This is good.
